November 05, 2009
Steven Schveighoffer wrote:
> Sounds good to me.  Should you also be able to mark a whole struct/class as @safe/@trusted, since it's generally a container for member functions?

Yes.

> Care to define some rules for "undefined behavior?"

I suppose I need to come up with a formal definition for it, but it's essentially meaning your program is going to do something arbitrary that's outside of the specification of the language. Basically, you're stepping outside of the domain of the language.

For example, assigning a random value to a pointer and then trying to read it is undefined behavior. Casting const away and then modifying the value is undefined behavior.
November 05, 2009
"Walter Bright" <newshound1@digitalmars.com> wrote in message news:hcvbu7$9i$1@digitalmars.com...
>
> For example, assigning a random value to a pointer and then trying to read it is undefined behavior.

How would the compiler be able to detect that? Or do you mean assigning an arbitrary value?


November 05, 2009
== Quote from Nick Sabalausky (a@a.a)'s article
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:hcvbu7$9i$1@digitalmars.com...
> >
> > For example, assigning a random value to a pointer and then trying to read it is undefined behavior.
> How would the compiler be able to detect that? Or do you mean assigning an arbitrary value?

How do you generate a random pointer without casting it from an int (not allowed
in SafeD) or doing pointer arithmetic (not allowed in SafeD)?
November 05, 2009
"Walter Bright" <newshound1@digitalmars.com> wrote in message news:hcv5p9$2jh1$1@digitalmars.com...
>
> Based on Andrei's and Cardelli's ideas, I propose that Safe D be defined as the subset of D that guarantees no undefined behavior. Implementation defined behavior (such as varying pointer sizes) is still allowed.
>
> Safety seems more and more to be a characteristic of a function, rather than a module or command line switch. To that end, I propose two new attributes:
>
> @safe
> @trusted
>

Sounds great! The lower-grained safeness makes a lot of sense, and I'm thrilled at the idea of safe D finally encompassing more than just memory safety - I'd been hoping to see that happen ever since I first heard that "safeD" only ment memory-safe.


November 05, 2009
Walter Bright:

> I agree. Also, dealing with safeness is something that comes later on as a project scales to a larger size. As such, it's more of a nuisance on a small program than a help.

I don't know. In modern languages safety is a starting point. Things are safe unless defined otherwise. In C# default is for safety.


> Right. Adding:
> 
>     @safe:
> 
> at the top will do it.

See my first answer to this thread.

And the same can be said about a modifier 'unsafe' that applies to the whole code of a module. So half of Tango will compile again.

Bye,
bearophile
November 05, 2009
On Thu, 05 Nov 2009 15:20:34 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Steven Schveighoffer wrote:
>> On Thu, 05 Nov 2009 14:57:48 -0500, Michel Fortin <michel.fortin@michelf.com> wrote:
>>
>>> On 2009-11-05 13:33:09 -0500, Walter Bright <newshound1@digitalmars.com> said:
>>>
>>>> Safety seems more and more to be a characteristic of a function, rather than a module or command line switch. To that end, I propose two new attributes:
>>>>  @safe
>>>> @trusted
>>>
>>> Looks like a good proposal.
>>>
>>> That said, since most functions are probably going to be safe, wouldn't it be better to remove @safe and replace it by its counterpart: an @unsafe attribute? This would make things safe by default, which is undoubtedly safer, and avoid the unnecessary clutter of @safe annotations everywhere.
>>  If unsafe means you cannot pass pointers to local variables, then half of tango (and other performance oriented libs which use stack allocation as much as possible) will fail to compile.
>
> While I agree with your point, quick question: could you use ref parameters instead? Ref will be usable in SafeD.

Most of the usages are like this:

ubyte[1024] buffer;
functionThatNeedsBufferSpace(buffer);

where functionThatNeedsBufferSpace takes a ubyte[], thereby taking an address of the local data.

So it's not explicit address taking, but it's the same thing under the hood.  There always exists the potential for the stack reference to escape.

Similar case is scope classes (which are sometimes used to allocate a temporary class for performance in tango).  I can't see scope classes being allowed if you can't take addresses of local variables.

I'm not saying that safed needs to allow these kinds of things somehow (thereby employing escape analysis), but it might be too restrictive for performance-oriented libs/apps.  I think it's acceptable that tango eventually gets marked with @trusted, but by making @safe the default, you will immediately make many D1 projects not compile without significant effort, which might drive away developers from D2, or else make people automatically mark all files as @trusted without thinking about it.  By defaulting to untrusted and unsafe, you allow people to incrementally add @safe and @trusted tags where they are appropriate and correct.

-Steve
November 05, 2009
bearophile wrote:
> 
> In C# you use something like:
> 
> unsafe {
>   // lot of code
> }
> 
> I think that's a good solution. Things are meant as safe unless marked as
> Unsafe. You can mark a whole block of code as unsafe putting it into
> those brackets. D may do the same. Also single functions may have the @unsafe
attribute.
>

That's not the whole story though.

Use an unsafe block and you have to throw the appropriate compiler switch '/unsafe' and your entire assembly can only be used if it's 'fully trusted'.

Though I forget exactly what that means, 'trust' is determined at runtime, so e.g. code run from a web browser can't call your assembly.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
November 05, 2009
safe should be the default. The unsafe part should take the extra typing, not the other way. Make the user prefer the safe way.
November 05, 2009
Frank Benoit wrote:
> safe should be the default. The unsafe part should take the extra
> typing, not the other way. Make the user prefer the safe way.

No. D is not C#.
November 05, 2009
Nick Sabalausky wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:hcvbu7$9i$1@digitalmars.com...
>> For example, assigning a random value to a pointer and then trying to read it is undefined behavior.
> 
> How would the compiler be able to detect that? Or do you mean assigning an arbitrary value? 

By disallowing casting an int to a pointer.