Alignment (or at least, rounding up the size of a structure to a multiple of the requested alignment) I think is also needed... it's been around for ages, and is now part of the C11 standard. Being able to set such attributes would be very useful for C/C++ interfaces.
On Tuesday, February 10, 2015 at 3:32:27 AM UTC+1, Jameson wrote: > > 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] > <javascript:>> 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. > >
