"instanceOf" trait for conditional implementations

Simen Kjaeraas simen.kjaras at gmail.com
Thu Oct 4 06:54:11 PDT 2012


On 2012-37-04 11:10, monarch_dodra <monarchdodra at gmail.com> wrote:

> One of the issues I've been running into more or less frequently lately  
> is the inability to extract an instance of a type when trying to do  
> conditional implementation specification.
>
> Let me explain myself. Using T.init is a no go, because:
> a) T might be "@disabled this()", making T.init illegal syntax (in  
> theory, currently "buggy")
> b) T.init is NOT an LValue, making code such is "is(typeof(T.init = 5))"  
> invalid
> c) You can try to use "T t = void", but you may also run into problems:
> c)1) If T is immutable, that's illegal.
> c)2) The compiler may complain if you use t, due to access to  
> uninitialized.
[snip: Good stuff]

I like this, and have had the exact same thought.

There is one thing I don't like, and that is your instanceOf could be
used to create an uninitialized T. In the interest of that (and brevity)
let me present my solution:

@property T instanceOf( T )( );

It works great in static if, and fails at link-time. The error message is
however far from perfect:
  Error 42: Symbol Undefined  
_D3foo24__T10instanceOfTS3foo1SZ10instanceOfFNdZS3foo1S

But I think that is better than giving developers a tool for instantiating
types that are not meant to be instantiated.

-- 
Simen


More information about the Digitalmars-d mailing list