April 16, 2012
Hi,

I'd like to have more informations about the subsets of D.
My current understanding is that D have at least one subset that is called
SafeD, I m reading that article about it right now:
http://dlang.org/safed.html
I first thought there was only SafeD but in a recent video from Lang.Next
mr Alexandrescu says there are several layers or something similar.
Am I correct?

Also, I would like to find a page on the website that list clearly what is in each subset. I couldn t find it so far but maybe I m not using the right words to search.


Thanks

Klaim / Joel Lamotte


April 16, 2012
Le 16/04/2012 10:40, Klaim - Joël Lamotte a écrit :
> Hi,
>
> I'd like to have more informations about the subsets of D.
> My current understanding is that D have at least one subset that is
> called SafeD, I m reading that article about it right now:
> http://dlang.org/safed.html
> I first thought there was only SafeD but in a recent video from
> Lang.Next mr Alexandrescu says there are several layers or something
> similar.
> Am I correct?
>
> Also, I would like to find a page on the website that list clearly what
> is in each subset. I couldn t find it so far but maybe I m not using the
> right words to search.
>
>
> Thanks
>
> Klaim / Joel Lamotte
>

@safe only allow operation that cannot screw up your memory. @system is the complete language.

@trusted is an explicit qualifie, to allow @safe code to call @system code. It is mandatory, for instance, for @safe code to call the GC (GC code cannot be @safe).

It is up to the develloper to ensure that @trusted code can really be trusted, so it isn't a subset.
April 16, 2012
On Mon, Apr 16, 2012 at 17:53, deadalnix <deadalnix@gmail.com> wrote:

>
> @safe only allow operation that cannot screw up your memory. @system is the complete language.
>
> @trusted is an explicit qualifie, to allow @safe code to call @system code. It is mandatory, for instance, for @safe code to call the GC (GC code cannot be @safe).
>
> It is up to the develloper to ensure that @trusted code can really be trusted, so it isn't a subset.
>


Thanks, it helps a bit.
However, a clear list of feature -> subset would be far more useful for me.

Klaim / Joel Lamotte


April 21, 2012
Am Mon, 16 Apr 2012 18:10:05 +0900
schrieb Klaim - Joël Lamotte <mjklaim@gmail.com>:

> On Mon, Apr 16, 2012 at 17:53, deadalnix <deadalnix@gmail.com> wrote:
> 
> >
> > @safe only allow operation that cannot screw up your memory. @system is the complete language.
> >
> > @trusted is an explicit qualifie, to allow @safe code to call @system code. It is mandatory, for instance, for @safe code to call the GC (GC code cannot be @safe).
> >
> > It is up to the develloper to ensure that @trusted code can really be trusted, so it isn't a subset.
> >
> 
> 
> Thanks, it helps a bit.
> However, a clear list of feature -> subset would be far more useful for me.
> 
> Klaim / Joel Lamotte

Since noone answered, I don't know what you heard in the video, but from my experience @safe is the only real subset that exists. And for you as the developer it means, that you can not use I/O and operations on pointers. Also when compiling in -release mode @safe keeps array bounds checks, while @system drops those checks. I imagine @safe code as encapsulated. It cannot talk to the outside world or access unrelated parts through pointer arithmetic. (Although, you can always call @trusted code which in turn calls @system code.) It's probably comparable to programming in a VM language like Java. You can apply @safe to either single functions or right at the top of your module to cover all code like so: "@safe:".

A feature table of @safe/@system is probably overkill, since most features still work. You just lose ASM/pointer arithmetics and direct calls to @system functions (which is the default). Work is on the way to mark as much of Phobos @safe as possible, since some functions still miss that attribute.

-- 
Marco

April 21, 2012
On Saturday, 21 April 2012 at 15:33:08 UTC, Marco Leise wrote:
> Since noone answered, I don't know what you heard in the video, but from my experience @safe is the only real subset that exists. And for you as the developer it means, that you can not use I/O and operations on pointers. Also when compiling in -release mode @safe keeps array bounds checks, while @system drops those checks. I imagine @safe code as encapsulated. It cannot talk to the outside world or access unrelated parts through pointer arithmetic. (Although, you can always call @trusted code which in turn calls @system code.) It's probably comparable to programming in a VM language like Java. You can apply @safe to either single functions or right at the top of your module to cover all code like so: "@safe:".
>
> A feature table of @safe/@system is probably overkill, since most features still work. You just lose ASM/pointer arithmetics and direct calls to @system functions (which is the default). Work is on the way to mark as much of Phobos @safe as possible, since some functions still miss that attribute.

There is a list at:

    http://dlang.org/function.html#function-safety

And a separate, apparently less-maintained list at:

    http://dlang.org/memory-safe-d.html

Phobos' I/O routines are @trusted, hence you can use them in SafeD.

SafeD is the only defined language subset of D that the specification and compiler deal with.
Top | Discussion index | About this forum | D home