I have a suggestion for yet another cool feature that would be nice to have in D...namely a *portability* attribute perhaps called

@portable

Any functions that are marked as @portable would be forbidden to do calculations whose result have different results on targets with different endianess. The only examples I can think of right now is:

- Reinterpreting pointers and ranges between types with different word size in a way that endianness would affect result (explicit use)
- Using unions with same effects (implicit use)

I'm guessing this static analysis would have similarities with how @safe functions are checked, right?

Also, can you think any other property than endiness-dependence such a property would forbid a function to have.

Destroy!

I think the problem here is there's too many functions that would need to be marked it to be useful and it isn't a big enough deal for most libs to bother.

> I think the problem here is there's too many functions that would need to be marked it to be useful and it isn't a big enough deal for most libs to bother.

Couldn't the compiler recursively infer this property for functions it has the complete (to the bottom) source for?

On Tuesday, 25 February 2014 at 23:12:37 UTC, Nordlöw wrote:
>> I think the problem here is there's too many functions that would need to be marked it to be useful and it isn't a big enough deal for most libs to bother.
>
> Couldn't the compiler recursively infer this property for functions it has the complete (to the bottom) source for?

Complete attribute inference was discussed ~year ago but is not on agenda right now. I don't think introduction of new attributes is feasible in practice until inference is implemented for existing ones.

On Tuesday, 25 February 2014 at 23:06:46 UTC, Adam D. Ruppe wrote:
> I think the problem here is there's too many functions that would need to be marked it to be useful and it isn't a big enough deal for most libs to bother.

I think the larger issue would be that the same people who understand when code would be endian-unsafe are the same ones who would try to write endian-safe code. People who don't know any better wouldn't know enough to mark their function unsafe.

> I think the larger issue would be that the same people who understand when code would be endian-unsafe are the same ones who would try to write endian-safe code. People who don't know any better wouldn't know enough to mark their function unsafe.

We could mark modules or even add a dmd flag, say -portable, though....

Just by curiosity:

What more than forbidding pointer-dribbling (casting and arithmetic) and unions with members smaller than word size should we require to be @portable?

On Tuesday, 25 March 2014 at 20:16:49 UTC, Nordlöw wrote:
> Just by curiosity:
>
> What more than forbidding pointer-dribbling (casting and arithmetic) and unions with members smaller than word size should we require to be @portable?

Your two are all that I can think of that are definitely dangerous, though I would state them as "All unions with types larger than a byte and any access through a pointer where the target type is larger than a byte." You could catch a few more by considering equals/or/and/xor between a large lvalue and a byte rvalue to be non-portable. Most cases like this will either be related to deserializing byte arrays or people hashing/encrypting data. Annoying for the latter group, but valid for the former.