[article] Language Design Deal Breakers

[Simen Kjaeraas]

On Tue, 28 May 2013 16:51:33 +0200, deadalnix <deadalnix at gmail.com> wrote:

> On Tuesday, 28 May 2013 at 13:17:37 UTC, Simen Kjaeraas wrote:
>> On Tue, 28 May 2013 05:35:22 +0200, deadalnix <deadalnix at gmail.com>  
>> wrote:
>>
>>> On Monday, 27 May 2013 at 21:55:00 UTC, Simen Kjaeraas wrote:
>>>> Now, if we wanted to add compiler support for non-nullable  
>>>> references, many
>>>> more things would need to be decided - how do they look? Do they  
>>>> assert
>>>> non-nullness upon initialization/assignment, or are external checks  
>>>> required?
>>>
>>> Same problem exists with any type with @disable this.
>>
>> Indeed. But not with @disable this() itself. If you don't like the way
>> it's implemented - roll your own, it's in the library.
>>
>
> @disable this isn't a feature you can implement as a lib. You can't roll  
> out your own.

Sorry, should have said "If you don't like the way NonNull!T is implemented
- roll your own, it's in the library."

Also, @disable this() enables non-nullable pointers, while non-nullable
pointers do not enable the equivalent of @disable this. @disable this is
more powerful *and* less design work. How can that not be better?


>>> It is. Having everybody considering it isn't is probably why you'll  
>>> find so much holes in NonNullable.
>>
>> It isn't. See above.
>
> It is; see above :D
>
> More generally, @disable this imply that you have to explicitly init  
> something. Just as non nullable. This is the exact same problem to solve.

I guess I should stop this now. I don't think we're getting anywhere we'd
want to be. :p

*sigh* No, it isn't. :p

non-nullable pointers is a subset of the possibilities enabled by @disable
this. This in itself makes it clear they're not solving the same problem
(more stuff is possible with @disable this() than non-nullable pointers).

Specifically, non-nullable pointers solve the problem of initializing
*pointers*, while @disable this() solves the problem of initializing
*anything*.

There. That's the differences.


Now, once @disable this() has been implemented, of course the groundwork
has been laid, and implementing non-nullable pointers is possible.
At that point we have two options: Implement non-nullable pointers in the
compiler, or as a library.

Implementing them in the compiler makes the compiler harder for others to
copy, and we want more implementations. Also, the syntax and behavior is
much more set in stone than if implemented in a library.

Implementing them as a library would let other compiler implementers use
the same implementation, and let users customize them if needed. There's
also less breakage of code if the implementation ever changes, because you
can just copy the old source (assuming the compiler is stable).

One could choose a hybrid approach, as has been the case with AAs -  
implement
NonNull!T in druntime, and add syntactic sugar in the compiler. This has  
many
of the advantages of a library solution *and* those of a compiler solution.
They do however tie the implementation closer to that of the compiler, and
the syntax and semantics must be much more precisely defined.

-- 
Simen