Where can I find more information on SafeD?

http://dlang.org/safed.html

google didn't seem to find much

Is this suitable for embedded targets such as ARM Cortex 32 bit?

thanks

Mark

> Is this suitable for embedded targets such as ARM Cortex 32 bit?

For ARM, your best bet is to follow this guide to build a GDC cross-compiler (probably easiest to build on a Linux host):

http://gdcproject.org/wiki/Cross%20Compiler/crosstool-NG

I don't know what kind of ARM Cortex you have in mind and what OS do you need to use. If you mean Cortex A8, A9 or A15 and if your target OS is GNU/Linux, then you can use Druntime and Phobos. I haven't used GDC on ARM enough to know if everything in Druntime and Phobos works, but the parts that I have used did work. In this case you should be able to SafeD too, as it's just a subset of D.

For Android there's a fork of GDC at https://github.com/jpf91/GDC/tree/android, but it hasn't been updated for some time now. There are build scripts that build NDK with gdc support at https://github.com/jpf91/gdc-android-scripts. I don't know how well that fork works. Also, GDC's Druntime does not support shared libraries, which is a problem if you want to call D functions from java apps.

If you are using some other OS or no OS at all, I don't think there is a working version of Druntime you can use. In that case, you could probably still use D, but without Druntime. You would need to write stubs for some Druntime functions to avoid linker errors, and you would need to avoid any D features that use Druntime. Because of that, you couldn't use any feature that use a GC, such as operator new, associative arrays, closures or appending to slices. This would also make it impossible to effectively use SafeD (because you wouldn't be able to allocate memory). You could port Druntime to your platform, but I guess this is a lot of work.

On Saturday, 9 March 2013 at 19:07:31 UTC, jerro wrote:
>> Is this suitable for embedded targets such as ARM Cortex 32 bit?
>
> For ARM, your best bet is to follow this guide to build a GDC cross-compiler (probably easiest to build on a Linux host):
>
> http://gdcproject.org/wiki/Cross%20Compiler/crosstool-NG
>
> I don't know what kind of ARM Cortex you have in mind and what OS do you need to use. If you mean Cortex A8, A9 or A15 and if your target OS is GNU/Linux, then you can use Druntime and Phobos. I haven't used GDC on ARM enough to know if everything in Druntime and Phobos works, but the parts that I have used did work. In this case you should be able to SafeD too, as it's just a subset of D.

   Thanks for the input - but where is SafeD defined? Is there a compiler switch?
I haven't looked at D in a while, it was just too big for ARM Cortex M, smaller PowerPC and similar targets - a google search got me to the SafeD topic.

On Saturday, March 09, 2013 20:47:10 Mark T wrote:
>     Thanks for the input - but where is SafeD defined? Is there a
> compiler switch?

No. It's simply code that's @safe. If you mark your functions as @safe, then they can only can @safe and @trusted functions and can't do any operations that the language considers to be @system (e.g. pointer arithmetic). So, what it comes down to is that you have certain safety guarantees about any code that's marked @safe. It's not really a separate language. It's just that you can only use a subset of the language within @safe code, because you can only use stuff that's guaranteed to be safe (though when calling @trusted code, you _do_ still rely on the programmer who wrote it having verified that it was actually safe, and they could screw that up).

Certain language constructs and core library components are not yet @safe like they should be, and attribute inferrence for templates still needs a lot of work (templated functions infer whether they're @safe, nothrow, and/or pure), so there's a lot of templated stuff that's perfectly safe but doesn't get treated that way yet. So, you're probably going to have to use @trusted more than would be desirable (and certainly more than you'll have to in the future), but on the whole, @safe itself works just fine. But it's part of the language, not something triggered by a compiler switch.

- Jonathan M Davis

On Saturday, 9 March 2013 at 19:47:12 UTC, Mark T wrote:
>    Thanks for the input - but where is SafeD defined? Is there a compiler switch?
> I haven't looked at D in a while, it was just too big for ARM Cortex M, smaller PowerPC and similar targets - a google search got me to the SafeD topic.

No, you don't need to compiler switch. What you need is to mark functions as @safe. E.g:

@safe void safe_foo()
{
}

If you don't mark them they are considerded @system.

On Saturday, 9 March 2013 at 19:47:12 UTC, Mark T wrote:
> On Saturday, 9 March 2013 at 19:07:31 UTC, jerro wrote:
>>> Is this suitable for embedded targets such as ARM Cortex 32 bit?
>>
>> For ARM, your best bet is to follow this guide to build a GDC cross-compiler (probably easiest to build on a Linux host):
>>
>> http://gdcproject.org/wiki/Cross%20Compiler/crosstool-NG
>>
>> I don't know what kind of ARM Cortex you have in mind and what OS do you need to use. If you mean Cortex A8, A9 or A15 and if your target OS is GNU/Linux, then you can use Druntime and Phobos. I haven't used GDC on ARM enough to know if everything in Druntime and Phobos works, but the parts that I have used did work. In this case you should be able to SafeD too, as it's just a subset of D.
>
>    Thanks for the input - but where is SafeD defined?

It is described in "The D programming language book". There's also something about it in "Programming in D" book, but that part hasn't been translated to English yet. People have written about SafeD in other places too, but I can't remember any.

> Is there a compiler switch?

There are attributes @safe, @trusted and @system, that are used like this:

void foo() @safe
{
    //some code
}

or

@safe
{
    void foo() @safe{}
    void bar() @safe{}
}

or (this will affect all the functions from @safe: to the end of the scope):

@safe:

void foo(){}
void bar(){}

The code that is marked as safe can't use certain language features (For example
pointer arithmetic and casting pointers - I haven't used @safe enough to know all the restrictions) or call functions that are marked @system. Also, some new restrictions (related to returning by reference) will need to be added to @safe, because it was recently discovered that it is currently possible to write @safe code that is not actually memory safe.

@system and @trusted code can use all D features and call all functions. The difference between them is that @trusted functions can be called by @safe code and @system functions can not.

For templates, safety is inferred from implementation if there are no attributes, and ordinary functions are considered @system by default.

> I haven't looked at D in a while, it was just too big for ARM Cortex M, smaller PowerPC and similar targets - a google search got me to the SafeD topic.

If D needs to much memory or if the executables are too large for your use case,
SafeD will not make it any better. It will actually make it worse, because it makes manual memory management impossible (it prohibits calling malloc or casting between pointer types), if used consistently.