556100 - const support in ctypes

Status: NEW

(Core :: js-ctypes, defect, P3)

Description

[[e-mail]]

Like so:

  let mutable_t = ctypes.int32_t.ptr;
  let const_t = mutable_t.const;

  let mutate = ctypes.FunctionType(ctypes.default_abi, ctypes.void_t, [ mutable_t ])();
  let read = ctypes.FunctionType(ctypes.default_abi, ctypes.void_t, [ const_t ])();
  // assume we populate these function pointers appropriately

  let i = mutable_t();
  mutate(i); // OK
  read(i);   // OK; implicitly cast nonconst -> const

  let j = const_t();
  mutate(j); // TypeError: got 'ctypes.int32_t.ptr.const', expect 'ctypes.int32_t.ptr'
  read(j);   // OK

This would be awesome for typechecking and readability, and stops people from using ctypes.cast (a dangerous stick indeed) to achieve these ends.

Is '.const' kosher as a property name in script?

P2; really nice to have for 1.9.3, and should be easy to implement.

Comment 1

[Jason Orendorff [:jorendorff]]

This is a breaking API change if you want to make JS strings act const.

Also note that if .const simply makes a type const, then:
  let mutable_t = ctypes.int32_t.ptr;      // int32_t *
  let const_t = mutable_t.const;           // int32_t * const
I think what you wanted was
  let const_t = ctypes.int32_t.const.ptr;  // const int32_t *

There is a significant difference in semantics; it's legal to pass an
(int32_t * const) where an (int32_t *) is expected.

I don't think const will be easy to implement... or easy to use. The rules are sensible but there are a lot of them and they get pretty subtle.

For example, given:
  typedef const int          const_int;
  typedef       int          array_of_int[4];
  typedef       const_int    array_of_const_int[4];
  typedef const array_of_int const_array_of_int;
are the last two the same type?

I suggest going after other stuff instead!