Charles D Hixson wrote:
> PPS:  When talking about casts or type conversions, please make it explicit whether the same bit pattern is maintained. I often read those descriptions, and realize that I can't figure out exactly what is happening.  With C I was always certain that I was just telling the compiler to think about the same piece of memory differently, and that nothing actually changed.


int i = 3;
double d = (double)i;

changes the bit pattern in C (as well as in D)

Walter Bright wrote:
> Clay Smith wrote:
>> Is SafeD just a label for the programmer selectively using D features?
> 
> Yes, but it would also be enforced by a compiler switch.

I think it's a great idea, then.

Hello Walter,

> Lars Ivar Igesund wrote:
> 
>> In light of this I find it rather incredible that printf still is
>> exposed through Object.
>> 
> printf would have to be removed from the safe D subset.
> 

Yay!!! That's great news

Walter Bright wrote:

> Lars Ivar Igesund wrote:
>> In light of this I find it rather incredible that printf still is exposed through Object.
> 
> printf would have to be removed from the safe D subset.

Point is that there is a useless _and_ unsafe global symbol/presence (only
in Phobos though).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Walter wrote:
>> Is SafeD just a label for the programmer selectively using D
>> features?
>> 
> Yes, but it would also be enforced by a compiler switch.

How will one assert that a library function is certified for usage in SafeD even if it uses unsafe constructs? New keywords?

Thanks

Walter Bright wrote:
> Charles D Hixson wrote:
>> PPS:  When talking about casts or type conversions, please make it explicit whether the same bit pattern is maintained. I often read those descriptions, and realize that I can't figure out exactly what is happening.  With C I was always certain that I was just telling the compiler to think about the same piece of memory differently, and that nothing actually changed.
> 
> 
> int i = 3;
> double d = (double)i;
> 
> changes the bit pattern in C (as well as in D)
O...K...
So I didn't understand them in C, either.  I'd been understanding them as a temporary substitute for a union for doing unsafe conversions.  (And avoiding them as much as possible.  Apparently just as well.)

"Julio César Carrascal Urquijo" <jcarrascal@gmail.com> wrote in message news:792eeb25153d8ca5b07163649b2@news.digitalmars.com...
> Walter wrote:
>>> Is SafeD just a label for the programmer selectively using D features?
>>>
>> Yes, but it would also be enforced by a compiler switch.
>
> How will one assert that a library function is certified for usage in SafeD even if it uses unsafe constructs? New keywords?
>
> Thanks
>
>

Maybe the compiler would just check the public interface?

Julio César Carrascal Urquijo wrote:
> How will one assert that a library function is certified for usage in SafeD even if it uses unsafe constructs? New keywords?

There'll have to be some syntax for that.

Walter Bright wrote:
> Clay Smith wrote:
>> Is SafeD just a label for the programmer selectively using D features?
> 
> Yes, but it would also be enforced by a compiler switch.

Hi Walter
Would it be better to implement a general framework for defining
code constraints ??

See Scott Meyers talk on Generalizing Const http://video.google.com/videoplay?docid=-4728145737208991310

Charles D Hixson wrote:
> 
> PPS:  When talking about casts or type conversions, please make it explicit whether the same bit pattern is maintained. I often read those descriptions, and realize that I can't figure out exactly what is happening.  With C I was always certain that I was just telling the compiler to think about the same piece of memory differently, and that nothing actually changed.  With more modern languages, a lot more magic happens under the hood, and I'm no longer as certain what's going on.  I often wonder after reading the documentation whether the same bit pattern is maintained, or whether an equivalent value is produced.  E.g., I've never tried casting a float to a long.  What would it produce?  I can't predict.  I'd often prefer to deal with ulongs or ucents rather than byte arrays, but then at other times I need to address particular bytes out of that value.  Because I don't really understand a cast, I just use byte arrays (well, ubyte).  But it's "sloppier".  Generally I'm dealing with a unitary entity, and needing to think of it as an array all the time is uncomfortable.  (I'd even like a notation for dealing with particular bits, though I haven't needed that recently.)
> Note that this isn't a request for a change in how things act, but rather in how they are documented.
> I *suspect* that cast is presumed to be defined by C, and that it means "Think about they type differently, but don't change it's bit pattern", but I'm never quite certain.

Yup, this is one of the C legacy behaviors/mentality that I've found ever more irritant. I would prefer that the language syntax would better distinguish between opaque casts (no bit changes) and conversion casts (bit changes, since a conversion is made).


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D