Oh my! My pencil is so *unsafe*. Whenever I try to write down this new no 1 chart hit, everybody just tells me my music sounds like crap.

Would someone here please provide me with a *safe* pencil?

Are there any developers left who can afford to choose their programming language for its expressive power and not for the amount of safety nets it provides. That is why D became my #1 language.

But I guess that's just someone speaking who, in the ol' days, didn't have a problem even in large C++ projects with matching each *new* at the start of a block with its *delete* at the end.

On Sunday, 5 January 2014 at 00:05:46 UTC, Walter Bright wrote:
> On 1/4/2014 3:04 PM, deadalnix wrote:
>> Because it is an instant crash,
>
> Would things going on and a random thing happening randomly later be better?

In a web-service server it is desirable to trap the SIGSEGV so that an appropriate http status can be returned before going down (telling the client to not do that again).

On Saturday, 4 January 2014 at 03:45:22 UTC, Maxim Fomin wrote:
> Why have you posted this ungrounded Rust advertisement anyway?

To spark discussion?

On 1/5/14, Adam D. Ruppe <destructionator@gmail.com> wrote:
> On Saturday, 4 January 2014 at 22:08:59 UTC, Andrej Mitrovic wrote:
>> Here you go:
>
> Genius!
>
> I'm pretty happy with that, and it can be used for all kinds of range checks following the same pattern.

Yeah. I've actually posted about this trick a few years ago, I think one of the main devs (Kenji/Walter) said it might be a bug that it works, but I've been using this for years and I think it deserves to be upgraded to be a full language feature (meaning we document it). It's been sitting in my library, here's some unittests:

https://github.com/AndrejMitrovic/minilib/blob/master/src/minilib/core/types.d#L98

Note how you can even use enforce.

On Sunday, 5 January 2014 at 00:49:43 UTC, Organic Farmer wrote:
> Are there any developers left who can afford to choose their programming language for its expressive power and not for the amount of safety nets it provides. That is why D became my #1 language.

Well it depends. On my case, the technology stack is always choosen from the customers.

Our freedom to choose is quite limited.

>
> But I guess that's just someone speaking who, in the ol' days, didn't have a problem even in large C++ projects with matching each *new* at the start of a block with its *delete* at the end.

I also don't have any problem, but my experience tells me that it doesn't scale when you have mixed experienced developers on teams scattered across multiple sites.

I had my share of tracking down pointer issues as senior developer covering up the mess, while customers were keeping the technical support ears warm. :(

I don't miss those days.

--
Paulo

On Sun, Jan 05, 2014 at 07:51:31AM +0000, digitalmars-d-bounces@puremagic.com wrote:
> On Sunday, 5 January 2014 at 00:05:46 UTC, Walter Bright wrote:
> >On 1/4/2014 3:04 PM, deadalnix wrote:
> >>Because it is an instant crash,
> >
> >Would things going on and a random thing happening randomly later be better?
> 
> In a web-service server it is desirable to trap the SIGSEGV so that an appropriate http status can be returned before going down (telling the client to not do that again).

Isn't that usually handled by running the webserver itself as a separate process, so that when the child segfaults the parent returns HTTP 501? Trusting the faulty process to return a sane status sounds rather risky to me (how do you know somebody didn't specially craft an attack to dump the contents of /etc/passwd to stdout, which gets redirected over the HTTP link? I rather the process segfault immediately rather than continuing to run when it detected an obvious logic problem with its own code).


T

-- 
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen

On Saturday, 4 January 2014 at 23:04:12 UTC, deadalnix wrote:
>> The list is endless. Why is null special?
>
> Because it is an instant crash, because it is not possible to make it safe without runtime check, because it is known to fool optimizer and cause really nasty bugs (typically, a pointer is dereferenced, so the optimizer assume it isn't null and remove null check after the dereference, and then the dereference is removed as it is dead. a bugguy code that could have crashed will know behave in random ways).

An instant crash is a very nice way to fail, compared to, for example, what failure means for an SQL injection or a buffer overrun. A crash is bad, but it's better than a program continuing to execute erroneously.

I have to agree with Walter here. Non-null is certainly nice, but it's just one kind of error out of a million, and not a particularly serious one at that.

On 2014-01-05 13:58, Paulo Pinto wrote:

> Well it depends. On my case, the technology stack is always choosen from
> the customers.
>
> Our freedom to choose is quite limited.

One could think that the technology stack is chosen based on the task it should solve.

-- 
/Jacob Carlborg

On Sunday, 5 January 2014 at 00:05:46 UTC, Walter Bright wrote:
>> Because it is an instant crash,
>
> Would things going on and a random thing happening randomly later be better?
>

Compile time error is preferable.

>> because it is not possible to make it safe
>> without runtime check,
>
> Wrapper types can handle this.
>
>> because it is known to fool optimizer and cause really
>> nasty bugs (typically, a pointer is dereferenced, so the optimizer assume it
>> isn't null and remove null check after the dereference, and then the dereference
>> is removed as it is dead.
>
> I'd like to see a case where this is nasty. I can't think of one.
>

A recent linux kernel exploit was caused by this. Reread carefully, this nasty behavior is created by the optimizer, and avoiding it mean preventing the optimizer to optimize aways loads, unless it can prove the pointer is non null. As D is meant to be fast, this limitation in the optimizer is highly undesirable.

>
>> a bugguy code that could have crashed will know behave
>> in random ways).
>
> Above it seems you were preferring it to fail in random ways rather than instant and obvious seg fault :-) For the record, I vastly prefer the instant seg fault.
>

You made that up. I do not prefers such behavior.

> I've posted a NonNull wrapper here a couple of times. I think it is adequately addressable at the library level, with the bonus that the same technique will work for other constrained types.
>

We already have a Nullable type as library.