[article] Language Design Deal Breakers

Timon Gehr timon.gehr at gmx.ch
Wed May 29 09:23:59 PDT 2013


On 05/29/2013 06:21 PM, Timon Gehr wrote:
> On 05/29/2013 07:35 AM, Walter Bright wrote:
>> On 5/28/2013 9:55 PM, Diggory wrote:
>>> As a last resort there should be a runtime check available such as
>>> assertNotNull(T) which does the conversion.
>>
>> The idea is to put the check on assignments to NotNull, not on usage
>> of it.
>
> This is like allowing assigning 'Object' references to 'Exception'
> references and adding a runtime check that the dynamic type actually
> conforms to 'Exception'.
>
> The current behaviour is like always allowing assigning 'Object' to
> 'Exception' but crashing when a method that is not present in 'Object'
> is called on an 'Exception' reference pointing to an 'Object'.
>
> Obviously both of those behaviours are not very sensible.
>
> What he is suggesting is something like this:
>
> // TODO: Add template constraints
>
> struct AnActual(T){
>      private T payload;
>      public T _upcastToNullable(){ return payload; }
>      alias _upcastToNullable this;
>      @disable this();
>      private this(T t){ payload = t; }
> }
>
> // ...

// Obviously here should be:

auto match(alias therecase, alias nullcase,T)(T t){
     if(t !is null) return therecase(AnActual!T(t));
     return nullcase();
}

> // ...
> // the following suffers from the inability to use a private
> // constructor to build a non-nullable object...
> auto New(T,S...)(S args){ return AnActual!T(new T(args)); }
>
>
> If you put these declarations in their own module, then the guarantee
> that AnActual!T does not contain null can be provided _statically_
> without any runtime checks. (modulo unsafe constructs, as always.)
>
>
> This still does not prevent dereferencing nullable pointers.



More information about the Digitalmars-d mailing list