On 1/4/2014 4:51 AM, Peter Alexander wrote:
> It's worth noting that many languages take a long time before they blossom. It
> took Ruby 10 years before Rails appeared.

Many languages have a long history before they burst on the scene. It's much like rock bands. The Beatles labored fruitlessly for years in the salt mines before appearing out of nowhere.

On 1/4/2014 4:44 AM, ilya-stromberg wrote:
> On Saturday, 4 January 2014 at 12:31:06 UTC, Iain Buclaw wrote:
>> Rust syntax changes every couple of months?!?!?
>
> It looks like yes: "The following code examples are valid as of
> Rust 0.8. Syntax and semantics may change in subsequent versions."
>
> http://en.wikipedia.org/wiki/Rust_%28programming_language%29

I attended a presentation on Rust a couple months ago, by one of the Rust developers, and he said his own slides were syntactically out of date :-)

On 1/4/2014 9:13 AM, Thiez wrote:
> On Saturday, 4 January 2014 at 04:20:30 UTC, David Nadlinger wrote:
>> This is not true. While it _is_ possible to get null pointers in @safe code,
>> they are not a safety problem, as the first page is never mapped in any D
>> processes (yes, I'm aware of the subtle issues w.r.t. object size here, c.f.
>> Bugzilla). And if you find a way to obtain a dangling pointer in @safe code,
>> please report it to the bug tracker, this is not supposed to happen.
>
> What happens when you have an object/array/struct/whatever that is larger than a
> page, and access one of the members/indices that is more than one page-size away
> from the starting point? Wouldn't this cause memory corrupting if the second
> page is mapped and you have a NULL pointer?

Yes, it would.

Many systems, in order to deal with this, map out the first 64K, not just the first page. Java, to deal with this, makes objects larger than 64K illegal.

On 1/4/2014 9:35 AM, Maxim Fomin wrote:
> There are many examples when one can get dangling pointer in @safe code, they
> are fixed slowly, almost never (like slicing static array - it was in bugzilla
> for some time and still not fixed AFAIK, let alone other issues which received
> zero response). By the way, asking to post such examples to bugzilla contradicts
> idea that it is impossible to have such kind of code. And being in bugzilla is
> not excuse for these bugs.

Pull requests to fix bugzilla issues are always welcome.

On 1/4/2014 6:51 AM, Adam D. Ruppe wrote:
> (though i think this is different in 32 and 64 bit, but as you'll probably
> remember, the interrupt table in 16 bit DOS was located at address 0.)

That was such a bad CPU design decision. It sure was a costly error. It would have been so much better to put the boot rom at address 0.

On Saturday, 4 January 2014 at 19:05:54 UTC, Walter Bright wrote:
> On 1/4/2014 5:49 AM, Timon Gehr wrote:
>> Hence it is fine to claim that the lack of dereferenceable null pointers makes a
>> language safer, even though it has no bearing on memory safety.
>
> I believe it is misusing the term by conflating safety with bug-free.

Dereferencing a null pointer is ALWAYS an error, just as dereferencing freed memory is.

On Saturday, 4 January 2014 at 19:11:27 UTC, Walter Bright wrote:
> Many systems, in order to deal with this, map out the first 64K, not just the first page. Java, to deal with this, makes objects larger than 64K illegal.

If linux and BSD style system aren't major, then that is true (mapped memory is variable on both).

Java do not limit the size of object to 64k, but the number of methods (or member, I don't have the spec on my eyes now). No size limit. Java rely on runtime checks for null.

On Saturday, 4 January 2014 at 19:05:00 UTC, Walter Bright wrote:
> On 1/4/2014 1:18 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> 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.
>
> Yes, the non-NULL thing is just one example of a useful constraint one can put on types.

Yes, exactly. And we have contact programming for this rules, but DMD doesn't support any contact checks at the compile time. Do you have any plans to improve the situation? For example, we can add `static in` and `static out` contacts.

Walter Bright:

> I believe it is misusing the term by conflating safety with bug-free.

Regarding the bugs, this is quoted from a recently shown open letter. It's about the Xamarin Studio, that I think is written in C#:
https://gist.github.com/anonymous/38850edf6b9105ee1f8a

>SH*TTON of null exceptions at runtime. Every now and then I get a nice error popup showing a null exception somewhere in Xamarin Studio. Most often this happens when I move a file, do some changes in Android UI designer or just do something non-trivial. And yes, I always restart the IDE after that, because when one exception pops up, many more are to come, so restart is mandatory here.<

If you write an IDE in D language you wish to avoid this situation :-)

Bye,
bearophile

On Saturday, 4 January 2014 at 17:57:26 UTC, Timon Gehr wrote:
> This mechanism would be more useful if moving was specified to occur whenever provably possible using live variable analysis.

Yes, I agree. I'd really like to have the unique and lent stuff.

> The following is possible:

Right, and it isn't too bad.