"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