On Thursday, 20 September 2012 at 14:15:23 UTC, monarch_dodra wrote:
> On Thursday, 20 September 2012 at 14:09:29 UTC, Namespace wrote:
>
>> http://dpaste.dzfl.pl/edit/361a54eb
>> With
>> [code]
>> @disable this(this);
>> [/code]
>> this don't work (as expected). But with the copy ctor but without ".get" you earn a segmentation fault (as you can see). So you can disable the copy ctor but without using .get you're not get what you want. Even with scoped, but scoped's getter name is too long.
>
> Wrong link.

Try this: http://dpaste.dzfl.pl/9247af54

On 09/20/2012 03:37 AM, monarch_dodra wrote:
> On Thursday, 20 September 2012 at 10:20:24 UTC, Johannes Pfau wrote:
>> http://dlang.org/struct.html
>> D classes do not really have copy constructors. You could assume that
>> if a constructor has only one argument and it's of the same type as
>> the class, it's a copy constructor.
>
> True... the term "copy constructor" is not 100% accurate, it is just "a
> constructor that takes the same type"
>
> A a = new A(); //Creates a new A
> A b = a; //Binds to the existing A
> A c = new A(a); //Constructs a new A, form an old A.

A polymorphic member function would be better for when A is just a base class, i.e. when we don't know its actual type (the virtual constructor idiom):

void foo(Animal a)
{
    Animal c = a.dup;  // can be any Animal
    // ...
}

Ali

On Thursday, 20 September 2012 at 15:04:48 UTC, Namespace wrote:
> On Thursday, 20 September 2012 at 14:15:23 UTC, monarch_dodra wrote:
>> On Thursday, 20 September 2012 at 14:09:29 UTC, Namespace wrote:
>>
>>> http://dpaste.dzfl.pl/edit/361a54eb
>>> With
>>> [code]
>>> @disable this(this);
>>> [/code]
>>> this don't work (as expected). But with the copy ctor but without ".get" you earn a segmentation fault (as you can see). So you can disable the copy ctor but without using .get you're not get what you want. Even with scoped, but scoped's getter name is too long.
>>
>> Wrong link.
>
> Try this: http://dpaste.dzfl.pl/9247af54

What did you expect? You are passing your OnStack by value. In this particular case, you are over destroying your OnStack!B, which in turn over destroyes his _a.

Reactivate the disable, and you'll see the problem blatantly:
http://dpaste.dzfl.pl/9e873033
/home/c192/c104.d(102): Error: struct c104.OnStack!(A).OnStack is not copyable because it is annotated with @disable

The "problem" with implicit cast is that *sometimes* you think it does it, but in fact, it doesn't. Here, it didn't.

The opCall expects Arg... so if you give it an OnStack, it accepts an OnStack. If you want it to take a T, you have to specify it, either in the template, or with get, or with a cast.

Here is a cast version, with this(this) disabled:
http://dpaste.dzfl.pl/837f44a9

I expect nothing, my only intention was to show you, that this cannot work. But that it works with an explicit cast is very impressive. I thought the alias this does it automatically.
I'm learning too. ;)