Walter Bright wrote:
> 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.

What does it matter to safe code if a library uses unsafe constructs internally?

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

Sounds great. Would it be possible to compile SafeD code to Java bytecode? iirc it isn't possible to do that with D.

Bruno Medeiros 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.  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).

I'm with you. The worst example: Despite the name, C++'s reinterpret_cast<> sometimes does _conversion casts_, involving bit changes.

Dejan Lekic wrote:
> This simple concept is amazing, as is the fact that Modula-3 (as a language) had this (plus numerous other modern features) two decades ago.

Features from Modula-3 make me nervous, as Modula-3 was an abject failure. I don't know why M3 failed, so I am suspicious of adopting features without thoroughly understanding why M3 failed.

Lutger wrote:
> Sounds great. Would it be possible to compile SafeD code to Java bytecode? iirc it isn't possible to do that with D.

It possibly could be.

Walter Bright wrote:
> Dejan Lekic wrote:
>> This simple concept is amazing, as is the fact that Modula-3 (as a language) had this (plus numerous other modern features) two decades ago.
> 
> Features from Modula-3 make me nervous, as Modula-3 was an abject failure. I don't know why M3 failed, so I am suspicious of adopting features without thoroughly understanding why M3 failed.

That particular feature, however, seems reasonable.  But I question the granularity.

I think that unsafe should be an attribute that could be set statically for a class or a function.  And read whenever you felt like reading it, of course.  But the question is, should it be set by the compiler, or by the programmer.  And what form should a check for safe vs. unsafe take?

One obvious form would be an assert check, but this presumes that unsafe code is allowed by default, and is only rejected if a test fails.

Another plausible approach would be to by default forbid the calling of unsafe code, and to have a pragma that allows it. This is a bit messy, as pragmas don't have nice boundary conditions.  (Rather like extern.  You either enable it for a statement/block, or for all succeeding statement/blocks. Still, a variation of pragma, the
pragma ( Identifier , ExpressionList )
form, could be nice.  I'm thinking of it having the form:
pragma (AllowUnsafe, class1, class2, etc, classk::unsafeFunction, etc.);
to allow the use of the specified unsafe code.  The reason for this form of the pragma is so that you don't accidentally allow all unsafe functions throughout and entire module by mistake.  Naturally the normal rules would still apply:  If you declared a pragma within a block, it would only apply within that block.

If you're adopting the pragma form, then the code could be detected as unsafe by the compiler, and only it's use forbidden (unless specifically allowed).

I haven't been able to think of any reason for dynamically allowing/forbidding the use of unsafe code, though I suppose such is possible.  In such a case it would probably be appropriate to use whatever form of allowance is decided upon, and then to forbid it with standard if statement (or try/catch blocks).

Walter Bright wrote:
> Bill Baxter wrote:
>> Is this something that actually exists?  Or just an idea being thrown around? Or just a marketing slogan for using D without pointers?
> 
> It's an idea for defining a language subset that is enforceable by the compiler.

Hmm.  This sounds like a big can of worms to me.  I'd rather have bug fixes or further progress on the WalterAndrei.pdf agenda than a compiler switch that forces me to use a restricted subset of D.  I guess I'm just not "enterprise" enough.   :-)

--bb

== Quote from Bill Baxter (dnewsgroup@billbaxter.com)'s article
> Walter Bright wrote:
> > Bill Baxter wrote:
> >> Is this something that actually exists?  Or just an idea being thrown around? Or just a marketing slogan for using D without pointers?
> >
> > It's an idea for defining a language subset that is enforceable by the compiler.
> Hmm.  This sounds like a big can of worms to me.  I'd rather have bug fixes or further progress on the WalterAndrei.pdf agenda than a compiler switch that forces me to use a restricted subset of D.  I guess I'm just not "enterprise" enough.   :-)

While you're at it, you may as well ask for all the features in the 1.0 spec to actually be implemented.  Why aim low?


Sean

I suspect that having a granular level of specifying safe/unsafe is the wrong approach. Doing it at the module level is easy to understand, and has the side effect of encouraging better modularization of safe/unsafe code.

Chris Miller Wrote:

> On Sat, 22 Mar 2008 21:47:59 -0700
> Walter Bright <newshound1@digitalmars.com> wrote:
> 
> > 
> > http://reddit.com/r/programming/info/6d210/comments/
> 
> I think this calls for a compiler switch that forces bounds checking on, whether or not debug or release mode. You don't want to be shipping debug code.
> 
> Also, a pragma or similar would be helpful; if it could enable bounds-checking from that point until the end of the scope, you could completely rely on bounds checks in your code, like you can do in other modern languages.
> 
> Finally, would SafeD have to disallow destructors? If you're accessing garbage collected memory in a destructor, you're asking for trouble. It's not always as simple as directly disallowing access these fields. Calling functions can indirectly cause the memory to be accessed. However, if you're not accessing GC memory in a destructor, you're probably using some lower-level functions, which are generally untrustworthy.

I thought the garbage collector only freed memory after the destructor had been run.

DMD 1.00 spec document, page 104 says "The garbage collector calls the destructor when the object is deleted."

Did this change?  I haven't checked for an update to my copy of the spec document in some time.

-- the "other" Chris Miller