SafeD is, unfortunately, not finished at the moment. I want to leave in
place a stub that won't lock our options. Here's what we currently have:

module(system) calvin;

This means calvin can do unsafe things.

module(safe) susie;

This means susie commits to extra checks and therefore only a subset of D.

module hobbes;

This means hobbes abides to whatever the default safety setting is.

The default safety setting is up to the compiler. In dmd by default it
is "system", and can be overridden with "-safe".

Sketch of the safe rules:

\begin{itemize*}
\item No @cast@ from a pointer type to an integral type and vice versa
\item No @cast@ between unrelated pointer types
\item Bounds checks on all array accesses
\item  No  unions  that  include  a reference  type  (array,  @class@,
pointer, or @struct@ including such a type)
\item No pointer arithmetic
\item No escape of a pointer  or reference to a local variable outside
its scope
\item Cross-module function calls must only go to other @safe@ modules
\end{itemize*}

So these are my thoughts so far. There is one problem though related to
the last \item - there's no way for a module to specify "trusted",
meaning: "Yeah, I do unsafe stuff inside, but safe modules can call me
no problem". Many modules in std fit that mold.

How can we address that? Again, I'm looking for a simple, robust,
extensible design that doesn't lock our options.

Thanks,

Andrei

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message
news:hcqb44$1nc9$1@digitalmars.com...
> SafeD is, unfortunately, not finished at the moment. I want to leave in
> place a stub that won't lock our options. Here's what we currently have:
>
> module(system) calvin;
>
> This means calvin can do unsafe things.
>
> module(safe) susie;
>
> This means susie commits to extra checks and therefore only a subset of D.
>
> module hobbes;
>
> This means hobbes abides to whatever the default safety setting is.
>
> The default safety setting is up to the compiler. In dmd by default it is
> "system", and can be overridden with "-safe".
>
> Sketch of the safe rules:
>
> \begin{itemize*}
> \item No @cast@ from a pointer type to an integral type and vice versa
> \item No @cast@ between unrelated pointer types
> \item Bounds checks on all array accesses
> \item  No  unions  that  include  a reference  type  (array,  @class@,
>   pointer, or @struct@ including such a type)
> \item No pointer arithmetic
> \item No escape of a pointer  or reference to a local variable outside
>   its scope
> \item Cross-module function calls must only go to other @safe@ modules
> \end{itemize*}
>
> So these are my thoughts so far. There is one problem though related to
> the last \item - there's no way for a module to specify "trusted",
> meaning: "Yeah, I do unsafe stuff inside, but safe modules can call me no
> problem". Many modules in std fit that mold.
>
> How can we address that? Again, I'm looking for a simple, robust,
> extensible design that doesn't lock our options.
>

module(system, trusted) calvin;
?

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
> SafeD is, unfortunately, not finished at the moment. I want to leave in
> place a stub that won't lock our options. Here's what we currently have:
> module(system) calvin;
> This means calvin can do unsafe things.
> module(safe) susie;
> This means susie commits to extra checks and therefore only a subset of D.
> module hobbes;
> This means hobbes abides to whatever the default safety setting is.
> The default safety setting is up to the compiler. In dmd by default it
> is "system", and can be overridden with "-safe".
> Sketch of the safe rules:
> \begin{itemize*}
> \item No @cast@ from a pointer type to an integral type and vice versa
> \item No @cast@ between unrelated pointer types
> \item Bounds checks on all array accesses
> \item  No  unions  that  include  a reference  type  (array,  @class@,
>    pointer, or @struct@ including such a type)
> \item No pointer arithmetic
> \item No escape of a pointer  or reference to a local variable outside
>    its scope
> \item Cross-module function calls must only go to other @safe@ modules
> \end{itemize*}
> So these are my thoughts so far. There is one problem though related to
> the last \item - there's no way for a module to specify "trusted",
> meaning: "Yeah, I do unsafe stuff inside, but safe modules can call me
> no problem". Many modules in std fit that mold.
> How can we address that? Again, I'm looking for a simple, robust,
> extensible design that doesn't lock our options.
> Thanks,
> Andrei

One comment that came up in discussing GC stuff in Bugzilla:  How do you prevent
the following in SafeD?

auto arrayOfRefs = new SomeClass[100];
GC.setAttr(arrayOfRefs.ptr, GC.BlkAttr.NO_SCAN);

foreach(ref elem; arrayOfRefs) {
elem = new SomeClass();
}

dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
>> SafeD is, unfortunately, not finished at the moment. I want to leave in
>> place a stub that won't lock our options. Here's what we currently have:
>> module(system) calvin;
>> This means calvin can do unsafe things.
>> module(safe) susie;
>> This means susie commits to extra checks and therefore only a subset of D.
>> module hobbes;
>> This means hobbes abides to whatever the default safety setting is.
>> The default safety setting is up to the compiler. In dmd by default it
>> is "system", and can be overridden with "-safe".
>> Sketch of the safe rules:
>> \begin{itemize*}
>> \item No @cast@ from a pointer type to an integral type and vice versa
>> \item No @cast@ between unrelated pointer types
>> \item Bounds checks on all array accesses
>> \item  No  unions  that  include  a reference  type  (array,  @class@,
>>    pointer, or @struct@ including such a type)
>> \item No pointer arithmetic
>> \item No escape of a pointer  or reference to a local variable outside
>>    its scope
>> \item Cross-module function calls must only go to other @safe@ modules
>> \end{itemize*}
>> So these are my thoughts so far. There is one problem though related to
>> the last \item - there's no way for a module to specify "trusted",
>> meaning: "Yeah, I do unsafe stuff inside, but safe modules can call me
>> no problem". Many modules in std fit that mold.
>> How can we address that? Again, I'm looking for a simple, robust,
>> extensible design that doesn't lock our options.
>> Thanks,
>> Andrei
>
> One comment that came up in discussing GC stuff in Bugzilla:  How do you prevent
> the following in SafeD?
>
> auto arrayOfRefs = new SomeClass[100];
> GC.setAttr(arrayOfRefs.ptr, GC.BlkAttr.NO_SCAN);
>
> foreach(ref elem; arrayOfRefs) {
>     elem = new SomeClass();
> }

Is GC.setAttr a safe function?

Andrei

Nick Sabalausky wrote:
> module(system, trusted) calvin;
> ?

Yah, I was thinking of something along those lines. What I don't like is
that trust is taken, not granted. But then a model with granted trust
would be more difficult to define.

Andrei

Andrei Alexandrescu, el  3 de noviembre a las 16:33 me escribiste:
> SafeD is, unfortunately, not finished at the moment. I want to leave
> in place a stub that won't lock our options. Here's what we
> currently have:
>
> module(system) calvin;
>
> This means calvin can do unsafe things.
>
> module(safe) susie;
>
> This means susie commits to extra checks and therefore only a subset of D.
>
> module hobbes;
>
> This means hobbes abides to whatever the default safety setting is.
>
> The default safety setting is up to the compiler. In dmd by default
> it is "system", and can be overridden with "-safe".

What's the rationale for letting the compiler decide? I can't see nothing
system, I think the default should be defined (I'm not sure what the
default should be though).

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Did you know the originally a Danish guy invented the burglar-alarm
unfortunately, it got stolen

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message
news:hcqc3m$1pgl$2@digitalmars.com...
> Nick Sabalausky wrote:
>> module(system, trusted) calvin;
>> ?
>
> Yah, I was thinking of something along those lines. What I don't like is
> that trust is taken, not granted. But then a model with granted trust
> would be more difficult to define.
>
> Andrei

import(trust) someSystemModule;
?

I get the feeling there's more to this issue than what I'm seeing...

Leandro Lucarella wrote:
> Andrei Alexandrescu, el  3 de noviembre a las 16:33 me escribiste:
>> SafeD is, unfortunately, not finished at the moment. I want to leave
>> in place a stub that won't lock our options. Here's what we
>> currently have:
>>
>> module(system) calvin;
>>
>> This means calvin can do unsafe things.
>>
>> module(safe) susie;
>>
>> This means susie commits to extra checks and therefore only a subset of D.
>>
>> module hobbes;
>>
>> This means hobbes abides to whatever the default safety setting is.
>>
>> The default safety setting is up to the compiler. In dmd by default
>> it is "system", and can be overridden with "-safe".
>
> What's the rationale for letting the compiler decide? I can't see nothing
> system, I think the default should be defined (I'm not sure what the
> default should be though).

The parenthesis pretty much destroys your point :o).

I don't think letting the implementation decide is a faulty model. If
you know what you want, you say it. Otherwise it means you don't care.

Andrei

Nick Sabalausky wrote:
> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message
> news:hcqc3m$1pgl$2@digitalmars.com...
>> Nick Sabalausky wrote:
>>> module(system, trusted) calvin;
>>> ?
>> Yah, I was thinking of something along those lines. What I don't like is
>> that trust is taken, not granted. But then a model with granted trust
>> would be more difficult to define.
>>
>> Andrei
>
> import(trust) someSystemModule;
> ?
>
> I get the feeling there's more to this issue than what I'm seeing...

There's a lot more, but there are a few useful subspaces. One is, if an
entire application only uses module(safe) that means there is no memory
error in that application, ever.

Andrei

On Tue, Nov 3, 2009 at 2:33 PM, Andrei Alexandrescu
<SeeWebsiteForEmail@erdani.org> wrote:
> SafeD is, unfortunately, not finished at the moment. I want to leave in
> place a stub that won't lock our options. Here's what we currently have:
>
> module(system) calvin;
>
> This means calvin can do unsafe things.
>
> module(safe) susie;
>
> This means susie commits to extra checks and therefore only a subset of D.
>
> module hobbes;
>
> This means hobbes abides to whatever the default safety setting is.
>
> The default safety setting is up to the compiler. In dmd by default it is
> "system", and can be overridden with "-safe".
>
> Sketch of the safe rules:
>
> \begin{itemize*}
> \item No @cast@ from a pointer type to an integral type and vice versa
> \item No @cast@ between unrelated pointer types
> \item Bounds checks on all array accesses
> \item  No  unions  that  include  a reference  type  (array,  @class@,
>  pointer, or @struct@ including such a type)
> \item No pointer arithmetic
> \item No escape of a pointer  or reference to a local variable outside
>  its scope
> \item Cross-module function calls must only go to other @safe@ modules
> \end{itemize*}
>
> So these are my thoughts so far. There is one problem though related to the
> last \item - there's no way for a module to specify "trusted", meaning:
> "Yeah, I do unsafe stuff inside, but safe modules can call me no problem".
> Many modules in std fit that mold.
>
> How can we address that? Again, I'm looking for a simple, robust, extensible
> design that doesn't lock our options.

I have to say that I would be seriously annoyed to see repeated
references to a feature that turns out to be vaporware.  (I'm guessing
there will be repeated references to SafeD based on the Chapter 4
sample, and I'm guessing it will be vaporware based on the question
you're asking above).  I'd say leave SafeD for the 2nd edition, and
just comment that work is underway in a "Future of D" chapter near the
end of the book.  And of course add a "Look to <the publishers website
|| digitalmars.com> for the latest!"

Even if not vaporware, it looks like whatever you write is going to be
about something completely untested in the wild, and so has a high
chance of turning out to need re-designing in the face of actual use.

--bb

« First   ‹ Prev
1 2 3 4 5