• =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= (17/17) Feb 25 2014 I have a suggestion for yet another cool feature that would be
• Adam D. Ruppe (3/3) Feb 25 2014 I think the problem here is there's too many functions that would
• =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= (2/5) Feb 25 2014 Couldn't the compiler recursively infer this property for
• Dicebot (5/10) Feb 25 2014 Complete attribute inference was discussed ~year ago but is not
• Chris Williams (5/8) Feb 25 2014 I think the larger issue would be that the same people who
• =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= (2/6) Mar 25 2014 We could mark modules or even add a dmd flag, say -portable,
• =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= (4/4) Mar 25 2014 Just by curiosity:
• Chris Williams (9/13) Mar 25 2014 Your two are all that I can think of that are definitely

=?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:

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!

"Adam D. Ruppe" <destructionator gmail.com> writes:

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.

=?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:

 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?

"Dicebot" <public dicebot.lv> writes:

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.

"Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:

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.

=?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:

 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....

=?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:

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?

"Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:

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.