Defaulting delegate member variables to do-nothing stubs

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 18, 2014 at 09:08:03PM +0300, ketmar via Digitalmars-d wrote:
> On Thu, 18 Sep 2014 10:47:39 -0700
> "H. S. Teoh via Digitalmars-d" <digitalmars-d at puremagic.com> wrote:
> 
> > Is there a way to achieve this? If not, why not?
> i believe that you can't put such delegate to .init due to
> required context pointer. yet compiler must be able to detect that this
> delegate is not using any context info and context pointer can be null
> here.
> 
> > Would it be worth filing an enhancement request for this?
> yes, i think that ER will be fine.

Right, that's the underlying problem. The compiler doesn't know that the
context pointer is not being used, so it bails out when not given a
context to point the pointer at.

	https://issues.dlang.org/show_bug.cgi?id=13494


> > Note that the lack of argumentless struct ctors exacerbates this
> > problem, since there is no way to work around the lack of language
> > support here.
> the only way is to @disable this(), so nobody will create unitialized
> struct. yet this reveals another bug(?):
> 
>   struct S {
>     int v;
>     @disable this ();
>     this (int n=42) { v = n; }
>   }
> 
>   void main () {
>     auto s = S();
>   }
> 
> z03.d(8): Error: constructor z03.S.this is not callable because it is
> annotated with @disable
> 
> WHAT? we have a perfectly valid struct constructor with default arg
> which can be called when S() constructed, yet compiler tells me that it
> can't do that, 'cause i disabled completely different constructor?
> 
> this thing annoys me alot, and i believe that i will eventually fix it
> regardless of it's status (bug/feature).

I think that should be filed as a bug. If the default ctor can't be
called (due to @disable), but there's another ctor with default
parameters, then the latter should be called instead.


T

-- 
The trouble with TCP jokes is that it's like hearing the same joke over and over.