> > Alignment (or at least, rounding up the size of a structure to a multiple > of the requested alignment)
See discussion here: https://github.com/JuliaLang/julia/issues/2555 I got a 404 error for that... can you please update the link? https://github.com/JuliaLang/julia/pull/7906 On Mon, Jun 1, 2015 at 2:00 AM, Scott Jones <[email protected]> wrote: > 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]> >> 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. >> >>
