[article] Language Design Deal Breakers

[Simen Kjaeraas]

On Mon, 27 May 2013 16:55:54 +0200, deadalnix <deadalnix at gmail.com> wrote:

> On Monday, 27 May 2013 at 14:36:26 UTC, Andrei Alexandrescu wrote:
>> On 5/27/13 5:17 AM, deadalnix wrote:
>>> I'm saying that NonNull require language support, either by making it a
>>> first class entity, or by introducing some other language feature like
>>> @disable this(). At the end it doesn't change anything for the  
>>> compiler,
>>> the exact same work have to be done, simply on different entities. It
>>> can't be a 100% library feature as the work around @disable this shows.
>>
>> The difference is that @disable this() and friends allows implementing  
>> NonNull PLUS a host of other restricted types, whereas plopping NonNull  
>> in the language just stops there. Big difference.
>>
>
> My point being that this is the exact same feature, from a compiler  
> perspective.
>
>>> I think that ideally, nonnull pointer should be a core feature.
>>> Considering history, a library solution is preferable.
>>>
>>> But the argument about compiler feature don't stand, as nonnull pointer
>>> and @disable this require the exact same processing in the compiler.
>>
>> No.
>>
>
> See above. Tracking initialization, that's it.

Well, yes. But it does so in a general way, rather than limit it to
non-nullable pointers/references.

If D had added non-nullable references only (no @disable this()), how would
you go about creating a number that's guaranteed to be prime? Would you ask
for that as a separate complier feature?

-- 
Simen