On 1/3/2014 6:27 PM, Kelet wrote:
> With Rust, there are no dangling or null pointers. This means that if a pointer
> exists, it points to a valid object of the appropriate type. When a pointer does
> not point to a valid object of the appropriate type, accessing the content at
> the pointer results in undefined behavior or an error in languages that allow
> it. Rust implements all of these pointer safety checks at compile time, so they
> do not incur a performance penalty. While `@safe` helps reduce this class of
> logic errors, it does not go so far as Rust -- you can still have null and
> dangling pointers, hence it is usually considered inferior with regards to
> safety.

Null pointers are not a safety issue. Safety means no memory corruption.


> There was a SafeD[1] subset of D being worked on, but I'm not sure if it
> is active anymore.

That became @safe, which is very much active.

On 01/04/2014 05:31 AM, Walter Bright wrote:
> ...
>
> Null pointers are not a safety issue.

In the general sense of the word, yes they are.

> Safety means no memory corruption.
> ...

That's memory safety.

On Saturday, 4 January 2014 at 04:26:24 UTC, Kelet wrote:
> Ultimately, it sounds like Rust primarily takes the 'default on' approach for things like safety and immutability, whereas D takes the 'default off' approach.

Sometimes the Rust approach is simply different. For instance, Rust disables global variables by default; (#[feature(globs)];) is needed to enable them, and all accesses must be declared unsafe. D on the other hand just makes them all thread-local, requiring explicit 'shared' declarations. I think the default D approach here may actually be safer, and is definitely more convenient.

On 1/3/2014 8:36 PM, Timon Gehr wrote:
> On 01/04/2014 05:31 AM, Walter Bright wrote:
>> ...
>>
>> Null pointers are not a safety issue.
>
> In the general sense of the word, yes they are.

Please explain.

On Saturday, 4 January 2014 at 05:16:38 UTC, Walter Bright wrote:
> On 1/3/2014 8:36 PM, Timon Gehr wrote:
>> On 01/04/2014 05:31 AM, Walter Bright wrote:
>>> ...
>>>
>>> Null pointers are not a safety issue.
>>
>> In the general sense of the word, yes they are.
>
> Please explain.

I don't know Timon Gehr's opinion, but it will be very nice to have NOT NULL pointers.

NULL pointer means that I don't have any valid object, and it's good situation. But there are a lot of situations when function must take a valid object (at least NOT NULL pointer). D allows:

1) use `if(p is null)` and than throw exception - it will be safe, but I have additional `if` check
2) ues `assert(p !is null)` - theoretically, it will be safe, but program can have different situation is realise mode and fails (for example, because nobody provide the same example in debug mode)
3) do nothing - programmer just forgot to add any checks

Also, I must to add unit tests for every posible case usage of that function with a valid object. So, it's kind of dynamic typing that can be done by compiler type system.

So, in a few cases null pointers are a safety issue.

On 1/3/2014 11:42 PM, ilya-stromberg wrote:
> NULL pointer means that I don't have any valid object, and it's good situation.
> But there are a lot of situations when function must take a valid object (at
> least NOT NULL pointer). D allows:
>
> 1) use `if(p is null)` and than throw exception - it will be safe, but I have
> additional `if` check
> 2) ues `assert(p !is null)` - theoretically, it will be safe, but program can
> have different situation is realise mode and fails (for example, because nobody
> provide the same example in debug mode)
> 3) do nothing - programmer just forgot to add any checks
>
> Also, I must to add unit tests for every posible case usage of that function
> with a valid object. So, it's kind of dynamic typing that can be done by
> compiler type system.
>
> So, in a few cases null pointers are a safety issue.

I believe this is a misunderstanding of what safety is. It means memory safety - i.e. no memory corruption. It does not mean "no bugs".

Memory corruption happens when you've got a pointer to garbage, and then you read/write that garbage.

Null pointers seg fault when they are dereferenced, halting your program. While a programming bug, it is not a safety issue.

The article, based on the title, struck me as FUD, and reading it just confirmed that suspicion.

It really is just an advertisement for Rust. And I like Rust, except for the buggy compiler and the near impossibility to do advanced metaprogramming techniques. But, I like D better, because (IMO) I can write more succinct, correct code without having to fight the type system, and do insanely powerful compile time and template magic (I'd like to note my project, Temple, as an example of how powerful D's CTFE is: github.com/dymk/temple).

From the article:
> and in particular does not provide safe constructs for concurrency

Did the author do their research at all? Of course D has safe constructs for concurrency, albeit optional ones.

On Saturday, 4 January 2014 at 07:42:51 UTC, ilya-stromberg wrote:
> I don't know Timon Gehr's opinion, but it will be very nice to have NOT NULL pointers.

I don't disagree, but isn't that just a special case of type constraints? Why limit it arbitrarily to null-values, limiting the range of values is useful for ints and floats too. If you move the constraint check to the function caller you can avoid testing when it isn't needed.

NoUseForAName:

> http://rust-class.org/pages/using-rust-for-an-undergraduate-os-course.html

Why aren't they using Ada? It has a really refined and safe parallelism, it's quite safe, it teaches a student the correct ways of dealing with pointers, memory etc in a low-level setting. It's usable for hard-realtime. And it's way more commonly used than Rust. There are books on Ada. Its compilers are solid, and while Ada is being updated significantly (the latest is Ada2012) there's no risk in having important parts of the language become backward incompatible in the short term. Ada code is not sexy, but this is not a significant problem for an advanced course lasting few months. Ada is a complex language, but it's the right kind of complexity, it's not special cases piled on special cases, it's features piled on features to deal correctly with different needs (just like in D, despite D is less designed for correctness compared to Ada).

Bye,
bearophile

On Saturday, 4 January 2014 at 11:36:20 UTC, bearophile wrote:
> NoUseForAName:
>
>> http://rust-class.org/pages/using-rust-for-an-undergraduate-os-course.html
>
> Why aren't they using Ada? It has a really refined and safe parallelism, it's quite safe, it teaches a student the correct ways of dealing with pointers, memory etc in a low-level setting. It's usable for hard-realtime. And it's way more commonly used than Rust. There are books on Ada. Its compilers are solid, and while Ada is being updated significantly (the latest is Ada2012) there's no risk in having important parts of the language become backward incompatible in the short term. Ada code is not sexy, but this is not a significant problem for an advanced course lasting few months. Ada is a complex language, but it's the right kind of complexity, it's not special cases piled on special cases, it's features piled on features to deal correctly with different needs (just like in D, despite D is less designed for correctness compared to Ada).
>
> Bye,
> bearophile

Ada is not hype enough, so it doesn't qualify. J/K (no death-threats please), I gave rust a try, i couldn't get it to run on my OS.