Well, whatever happens, I really hope that I don't have to start adding tests for null before using a library function just because the non-nullable type system cannot establish that a pointer is not null and therefore flags it as a compile-time error.

That would be annoying.

In my opinion a constraint system should go hand in hand with higher-level symbolic optimization (think maxima etc), but I think more polish is needed on what is in the language first…

What could be useful was whole program analysis that moves checks to the calling code where possible, because then hopefully the backend will remove some of the checks and it might make more sense to leave them in for more than debugging. If each function has two entry points that could probably work out fine, if the backends can handle it (which they probably don't if they are C-centric).

Hm, this is probably the one of the few time in my life that I have felt an urge to revisit Ole-Johan Dahl's book Verifiable Programming... The treatment of types was pretty nice though IIRC (proving correspondence between formal type definitions used for proofs of correctness and implementations or something like that).

On 1/4/2014 2:24 PM, Timon Gehr wrote:
> On 01/04/2014 09:16 PM, Walter Bright wrote:
>>
>> Non-NULL is really only a particular case of having a type with a
>> constrained set of values. It isn't all that special.
>
> If you allow a crude analogy: Constraining a nullable pointer to be not null is
> like sending an invitation to your birthday party to all your friends and also
> Chuck, including a notice that Chuck cannot come. You are defending this
> practise based on the observation that some birthday parties have a required
> dress code.

No, I am not defending it. I am pointing out that there's excessive emphasis on just one hole in that cheesegrater.

On Saturday, 4 January 2014 at 22:36:38 UTC, Walter Bright wrote:
> No, I am not defending it. I am pointing out that there's excessive emphasis on just one hole in that cheesegrater.

I think that's because it's the one "hole in the cheesegrater" that matters to most people. A non-null constraint has an effect on a lot more code than a "must be prime" constraint, for instance.

On Saturday, 4 January 2014 at 22:06:13 UTC, Walter Bright wrote:
> I don't really understand your point. Null is not that special.
>
> For example, you may want a constrained type:
>
> 1. a float guaranteed to be not NaN
> 2. a code point guaranteed to be a valid code point
> 3. a prime number guaranteed to be a prime number
> 4. a path+filename guaranteed to be well-formed according to operating system rules
> 5. an SQL argument guaranteed to not contain an injection attack
>
> 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).

On the other hand, it is really easy to make all of this burden disappear at language level.

2 should also be ensure by @safe .

3, 4, 5 can easily be ensured by current type system.

I'm not knowledgeable enough on floating point standard to express any opinion on 1.

On Saturday, 4 January 2014 at 21:03:53 UTC, H. S. Teoh wrote:
> I never trusted in the "hot new emerging trends" thing. Artifacts of
> quality take time to produce and develop, and bandwagons have a
> reputation of turning out to be disappointments. That goes for
> programming languages, and also software in general. What stands the test of time is what has the real value.
>
>
> T

Yeah, the statement would have better been written, "D has been around more than 10 years now, without much adoption and been through internal segregation but appears to be pushing through and increasing development support. While this past is concerning, it has at least demonstrated survival ability."

But I'm not sure that is obvious from the outside, there certainly is evidence that supports it.

On Saturday, 4 January 2014 at 04:49:47 UTC, logicchains wrote:
> 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.

Even then they aren't really globals, they have module scope; it is a small distinction and may not be applicable to a comparison to Rust.

On Saturday, 4 January 2014 at 23:04:12 UTC, deadalnix wrote:
> Because it is an instant crash, because it is not possible to

Actually, array out of bounds is no less an instant "crash" than trapping page 0 which is similar to implementing stack increase by trapping page faults.

What is likely to happen if you add non-null-pointers without organization wide code reviews to enforce them, or a state-of-the-art partial correctness proof system to back it up, is that people create null objects and point to those instead. And that will solve absolutely no bugs.

It makes more sense for high-level languages than for those languages who will receive a steady stream of null pointers from various libraries. It makes sense for Rust, because it is a priority issue for the organization backing the project. It might have made sense for Go which is trying to stay tiny and not low level and don't care all that much about performance, but for D… get the feature set stable and prove that correct (sound) before starting on a route to a partial correctness proof system.

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.

On 1/4/2014 3:04 PM, deadalnix wrote:
> On Saturday, 4 January 2014 at 22:06:13 UTC, Walter Bright wrote:
>> I don't really understand your point. Null is not that special.
>>
>> For example, you may want a constrained type:
>>
>> 1. a float guaranteed to be not NaN
>> 2. a code point guaranteed to be a valid code point
>> 3. a prime number guaranteed to be a prime number
>> 4. a path+filename guaranteed to be well-formed according to operating system
>> rules
>> 5. an SQL argument guaranteed to not contain an injection attack
>>
>> The list is endless. Why is null special?
>
> Because it is an instant crash,

Would things going on and a random thing happening randomly later be better?

> 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 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.


> On the other hand, it is really easy to make all of this burden disappear at
> language level.

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.


> 2 should also be ensure by @safe .

@safe is for memory safety.


> 3, 4, 5 can easily be ensured by current type system.

By exactly the same technique as non-null can be. Non-null does not require a special language case.


> I'm not knowledgeable enough on floating point standard to express any opinion
> on 1.

It's the same issue.

On 1/4/2014 2:41 PM, Chris Cain wrote:
> On Saturday, 4 January 2014 at 22:36:38 UTC, Walter Bright wrote:
>> No, I am not defending it. I am pointing out that there's excessive emphasis
>> on just one hole in that cheesegrater.
>
> I think that's because it's the one "hole in the cheesegrater" that matters to
> most people. A non-null constraint has an effect on a lot more code than a "must
> be prime" constraint, for instance.

If you look at code carefully, you'll see that most usages of types are constrained. Not only that, an awful lot of types have an "invalid" value, which is used to denote an error or missing data. The classic would be the -1 values returned by many C int returning functions. Using those without checking first doesn't even give the courtesy of a seg fault.

I think a solution that potentially plugs all the holes in a cheesegrater rather than only one would be better.