That's a pretty reasonable idea. There's even a few more attributes (coming from llvm and the platform ABI), that I would add to the list (such as float-compatible, complex-compatible, unsigned/signed).
However, it's unlikely to happen because it's also a lot more work on everyone. The more types of types that get introduced, the more interactions they start to have and it can get a bit hard to manage for both code authors and compiler writers. Supporting all the same set of operations as C is a partial goal, but supporting them with exactly the same semantics is not. I expect at some future point, immutable will become synonymous with inline and `const` annotations will be allowed on individual fields of mutable types. This is similar to what you are suggestion, although it comes at it from a slightly different angle. (packed is usually something else – however, the ability to specify arbitrary offsets for fields in a type is also something that will likely be implemented in the future) > As an aside, the standard lib breaks immutability with char arrays for fast ASCII string joins, though that usage should be safe as it is in the scope of the allocating method. I've occasionally tried to convert such code when I come across it to create an array first, then to turn that into a String. That has the same allocation semantics, but doesn't ignore the the intended immutability of strings. Although, as you pointed out, in practice, it doesn't matter here. On Mon Feb 09 2015 at 9:14:18 PM Michael Francis <[email protected]> wrote: > It does sound like immutable has been conflated with packed data > structures. That seems unfortunate. It would be nice if the properties of a > type could be selected at create time rather than with specific reserved > words. Something like the following. > > type Buffer <: Immutable,Packed > a::Int64 > end > > Though my preference would be to remove the reserved keywords all together. > > Buffer = type( > a::Int64 > ; flags = immutable | packed > ) > > Which is just a function which happens to register a type and has a few > named args. > > As an aside, the standard lib breaks immutability with char arrays for > fast ASCII string joins, though that usage should be safe as it is in the > scope of the allocating method.
