July 14, 2012
2012/7/15 Benjamin Thaut <code@benjamin-thaut.de>:
> The only problem about this is:
>
> class Fruit
> {
>   class Seed {
>     void SetFruit(Fruit fruit)
>     {
>       this.outer = fruit;

Setting to pseudo variable 'outer' should be rejected in compilation. Please report it to bugzilla.

>     }
>   }
> }
>
> class Apple: Fruit
> {
>   void AppleOnlyMethod(){ ... }
>
>   class AppleSeed: Fruit.Seed {
>     void DoSomething()
>     {
>       AppleOnlyMethod();
>     }
>   }
>
>   auto GetNewSeed() { return new AppleSeed(); }
> }
>
> auto apple = new Apple();
> auto seed = apple.GetNewSeed();
> seed.SetFruit(new Fruit());
> seed.DoSomething(); //what happens here?
>
> Kind Regards
> Benjamin Thaut
>

Kenji Hara
July 14, 2012
Am 14.07.2012 19:21, schrieb kenji hara:
> 2012/7/15 Benjamin Thaut <code@benjamin-thaut.de>:
>> The only problem about this is:
>>
>> class Fruit
>> {
>>    class Seed {
>>      void SetFruit(Fruit fruit)
>>      {
>>        this.outer = fruit;
>
> Setting to pseudo variable 'outer' should be rejected in compilation.
> Please report it to bugzilla.
>
>>      }
>>    }
>> }
>>
>> class Apple: Fruit
>> {
>>    void AppleOnlyMethod(){ ... }
>>
>>    class AppleSeed: Fruit.Seed {
>>      void DoSomething()
>>      {
>>        AppleOnlyMethod();
>>      }
>>    }
>>
>>    auto GetNewSeed() { return new AppleSeed(); }
>> }
>>
>> auto apple = new Apple();
>> auto seed = apple.GetNewSeed();
>> seed.SetFruit(new Fruit());
>> seed.DoSomething(); //what happens here?
>>
>> Kind Regards
>> Benjamin Thaut
>>
>
> Kenji Hara
>

I will not report this, beacuse it will break my custom new operator (template) for inner classes ;-)

Kind Regards
Benjamin Thaut

July 14, 2012
On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut <code@benjamin-thaut.de>wrote:

> Am 14.07.2012 19:21, schrieb kenji hara:
>
>> 2012/7/15 Benjamin Thaut <code@benjamin-thaut.de>:
>>
>>  The only problem about this is:
>>>
>>> class Fruit
>>> {
>>>    class Seed {
>>>      void SetFruit(Fruit fruit)
>>>      {
>>>        this.outer = fruit;
>>>
>>
>> Setting to pseudo variable 'outer' should be rejected in compilation. Please report it to bugzilla.
>>
>>       }
>>>    }
>>> }
>>>
>>> class Apple: Fruit
>>> {
>>>    void AppleOnlyMethod(){ ... }
>>>
>>>    class AppleSeed: Fruit.Seed {
>>>      void DoSomething()
>>>      {
>>>        AppleOnlyMethod();
>>>      }
>>>    }
>>>
>>>    auto GetNewSeed() { return new AppleSeed(); }
>>> }
>>>
>>> auto apple = new Apple();
>>> auto seed = apple.GetNewSeed();
>>> seed.SetFruit(new Fruit());
>>> seed.DoSomething(); //what happens here?
>>>
>>> Kind Regards
>>> Benjamin Thaut
>>>
>>>
>> Kenji Hara
>>
>>
> I will not report this, beacuse it will break my custom new operator
> (template) for inner classes ;-)
>
> Kind Regards
> Benjamin Thaut
>
>
That's most unwise, because if it's not supposed to be like that it will get fixed anyway, so you better start replacing your custom new operator.

-- 
Bye,
Gor Gyolchanyan.


July 14, 2012
Am 14.07.2012 19:30, schrieb Gor Gyolchanyan:
> On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut <code@benjamin-thaut.de
> <mailto:code@benjamin-thaut.de>> wrote:
>
>     Am 14.07.2012 19:21, schrieb kenji hara:
>
>         2012/7/15 Benjamin Thaut <code@benjamin-thaut.de
>         <mailto:code@benjamin-thaut.de>>:
>
>             The only problem about this is:
>
>             class Fruit
>             {
>                 class Seed {
>                   void SetFruit(Fruit fruit)
>                   {
>                     this.outer = fruit;
>
>
>         Setting to pseudo variable 'outer' should be rejected in
>         compilation.
>         Please report it to bugzilla.
>
>                   }
>                 }
>             }
>
>             class Apple: Fruit
>             {
>                 void AppleOnlyMethod(){ ... }
>
>                 class AppleSeed: Fruit.Seed {
>                   void DoSomething()
>                   {
>                     AppleOnlyMethod();
>                   }
>                 }
>
>                 auto GetNewSeed() { return new AppleSeed(); }
>             }
>
>             auto apple = new Apple();
>             auto seed = apple.GetNewSeed();
>             seed.SetFruit(new Fruit());
>             seed.DoSomething(); //what happens here?
>
>             Kind Regards
>             Benjamin Thaut
>
>
>         Kenji Hara
>
>
>     I will not report this, beacuse it will break my custom new operator
>     (template) for inner classes ;-)
>
>     Kind Regards
>     Benjamin Thaut
>
>
> That's most unwise, because if it's not supposed to be like that it will
> get fixed anyway, so you better start replacing your custom new operator.
>
> --
> Bye,
> Gor Gyolchanyan.

Replacing my custom new operator exactly by what? Overloading the build in new is deprecated...

July 15, 2012
On 07/15/2012 12:55 AM, Benjamin Thaut wrote:
> Am 14.07.2012 19:30, schrieb Gor Gyolchanyan:
>> On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut <code@benjamin-thaut.de
>> <mailto:code@benjamin-thaut.de>> wrote:
>>
>> Am 14.07.2012 19:21, schrieb kenji hara:
>>
>> 2012/7/15 Benjamin Thaut <code@benjamin-thaut.de
>> <mailto:code@benjamin-thaut.de>>:
>>
>> The only problem about this is:
>>
>> class Fruit
>> {
>> class Seed {
>> void SetFruit(Fruit fruit)
>> {
>> this.outer = fruit;
>>
>>
>> Setting to pseudo variable 'outer' should be rejected in
>> compilation.
>> Please report it to bugzilla.
>>
>> }
>> }
>> }
>>
>> class Apple: Fruit
>> {
>> void AppleOnlyMethod(){ ... }
>>
>> class AppleSeed: Fruit.Seed {
>> void DoSomething()
>> {
>> AppleOnlyMethod();
>> }
>> }
>>
>> auto GetNewSeed() { return new AppleSeed(); }
>> }
>>
>> auto apple = new Apple();
>> auto seed = apple.GetNewSeed();
>> seed.SetFruit(new Fruit());
>> seed.DoSomething(); //what happens here?
>>
>> Kind Regards
>> Benjamin Thaut
>>
>>
>> Kenji Hara
>>
>>
>> I will not report this, beacuse it will break my custom new operator
>> (template) for inner classes ;-)
>>
>> Kind Regards
>> Benjamin Thaut
>>
>>
>> That's most unwise, because if it's not supposed to be like that it will
>> get fixed anyway, so you better start replacing your custom new operator.
>>
>> --
>> Bye,
>> Gor Gyolchanyan.
>
> Replacing my custom new operator exactly by what? Overloading the build
> in new is deprecated...
>

class C{
    class D{

    }
}
void main(){
    auto c = new C;
    auto buf = new void[__traits(classInstanceSize, C.D)];
    (cast(byte[])buf)[] = typeid(C.D).init[];
    auto d = cast(C.D)buf.ptr;
    static if(is(typeof(d.__ctor()))) d.__ctor();
    enum offset=d.outer.offsetof;
    static assert(offset%C.sizeof==0);
    (cast(C[])buf)[offset/C.sizeof]=c;
    assert(d.outer is c);
}
July 15, 2012
Am 15.07.2012 02:02, schrieb Timon Gehr:
> On 07/15/2012 12:55 AM, Benjamin Thaut wrote:
>> Am 14.07.2012 19:30, schrieb Gor Gyolchanyan:
>>> On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut <code@benjamin-thaut.de
>>> <mailto:code@benjamin-thaut.de>> wrote:
>>>
>>> Am 14.07.2012 19:21, schrieb kenji hara:
>>>
>>> 2012/7/15 Benjamin Thaut <code@benjamin-thaut.de
>>> <mailto:code@benjamin-thaut.de>>:
>>>
>>> The only problem about this is:
>>>
>>> class Fruit
>>> {
>>> class Seed {
>>> void SetFruit(Fruit fruit)
>>> {
>>> this.outer = fruit;
>>>
>>>
>>> Setting to pseudo variable 'outer' should be rejected in
>>> compilation.
>>> Please report it to bugzilla.
>>>
>>> }
>>> }
>>> }
>>>
>>> class Apple: Fruit
>>> {
>>> void AppleOnlyMethod(){ ... }
>>>
>>> class AppleSeed: Fruit.Seed {
>>> void DoSomething()
>>> {
>>> AppleOnlyMethod();
>>> }
>>> }
>>>
>>> auto GetNewSeed() { return new AppleSeed(); }
>>> }
>>>
>>> auto apple = new Apple();
>>> auto seed = apple.GetNewSeed();
>>> seed.SetFruit(new Fruit());
>>> seed.DoSomething(); //what happens here?
>>>
>>> Kind Regards
>>> Benjamin Thaut
>>>
>>>
>>> Kenji Hara
>>>
>>>
>>> I will not report this, beacuse it will break my custom new operator
>>> (template) for inner classes ;-)
>>>
>>> Kind Regards
>>> Benjamin Thaut
>>>
>>>
>>> That's most unwise, because if it's not supposed to be like that it will
>>> get fixed anyway, so you better start replacing your custom new
>>> operator.
>>>
>>> --
>>> Bye,
>>> Gor Gyolchanyan.
>>
>> Replacing my custom new operator exactly by what? Overloading the build
>> in new is deprecated...
>>
>
> class C{
>      class D{
>
>      }
> }
> void main(){
>      auto c = new C;
>      auto buf = new void[__traits(classInstanceSize, C.D)];
>      (cast(byte[])buf)[] = typeid(C.D).init[];
>      auto d = cast(C.D)buf.ptr;
>      static if(is(typeof(d.__ctor()))) d.__ctor();
>      enum offset=d.outer.offsetof;
>      static assert(offset%C.sizeof==0);
>      (cast(C[])buf)[offset/C.sizeof]=c;
>      assert(d.outer is c);
> }

Yes of course I can assign the reference by computing the address and then using that to assign it. But the point here is, that this is currently the only bug that is hepling me in what I'm doing, and I rather want the 7 other bugs I reported so far to be fixed, rather then the one that helps me.

Kind Regards
Benjamin Thaut

July 15, 2012
On Sun, Jul 15, 2012 at 1:41 PM, Benjamin Thaut <code@benjamin-thaut.de>wrote:

> Am 15.07.2012 02:02, schrieb Timon Gehr:
>
>  On 07/15/2012 12:55 AM, Benjamin Thaut wrote:
>>
>>> Am 14.07.2012 19:30, schrieb Gor Gyolchanyan:
>>>
>>>> On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut <code@benjamin-thaut.de <mailto:code@benjamin-thaut.de**>> wrote:
>>>>
>>>> Am 14.07.2012 19:21, schrieb kenji hara:
>>>>
>>>> 2012/7/15 Benjamin Thaut <code@benjamin-thaut.de <mailto:code@benjamin-thaut.de**>>:
>>>>
>>>> The only problem about this is:
>>>>
>>>> class Fruit
>>>> {
>>>> class Seed {
>>>> void SetFruit(Fruit fruit)
>>>> {
>>>> this.outer = fruit;
>>>>
>>>>
>>>> Setting to pseudo variable 'outer' should be rejected in
>>>> compilation.
>>>> Please report it to bugzilla.
>>>>
>>>> }
>>>> }
>>>> }
>>>>
>>>> class Apple: Fruit
>>>> {
>>>> void AppleOnlyMethod(){ ... }
>>>>
>>>> class AppleSeed: Fruit.Seed {
>>>> void DoSomething()
>>>> {
>>>> AppleOnlyMethod();
>>>> }
>>>> }
>>>>
>>>> auto GetNewSeed() { return new AppleSeed(); }
>>>> }
>>>>
>>>> auto apple = new Apple();
>>>> auto seed = apple.GetNewSeed();
>>>> seed.SetFruit(new Fruit());
>>>> seed.DoSomething(); //what happens here?
>>>>
>>>> Kind Regards
>>>> Benjamin Thaut
>>>>
>>>>
>>>> Kenji Hara
>>>>
>>>>
>>>> I will not report this, beacuse it will break my custom new operator
>>>> (template) for inner classes ;-)
>>>>
>>>> Kind Regards
>>>> Benjamin Thaut
>>>>
>>>>
>>>> That's most unwise, because if it's not supposed to be like that it will get fixed anyway, so you better start replacing your custom new operator.
>>>>
>>>> --
>>>> Bye,
>>>> Gor Gyolchanyan.
>>>>
>>>
>>> Replacing my custom new operator exactly by what? Overloading the build in new is deprecated...
>>>
>>>
>> class C{
>>      class D{
>>
>>      }
>> }
>> void main(){
>>      auto c = new C;
>>      auto buf = new void[__traits(**classInstanceSize, C.D)];
>>      (cast(byte[])buf)[] = typeid(C.D).init[];
>>      auto d = cast(C.D)buf.ptr;
>>      static if(is(typeof(d.__ctor()))) d.__ctor();
>>      enum offset=d.outer.offsetof;
>>      static assert(offset%C.sizeof==0);
>>      (cast(C[])buf)[offset/C.**sizeof]=c;
>>      assert(d.outer is c);
>> }
>>
>
> Yes of course I can assign the reference by computing the address and then using that to assign it. But the point here is, that this is currently the only bug that is hepling me in what I'm doing, and I rather want the 7 other bugs I reported so far to be fixed, rather then the one that helps me.
>
> Kind Regards
> Benjamin Thaut
>
>
Don't you understand? It doesn't matter how much a bug helps you (or anything else for that matter) if it's a bug - it's gonna be fixed. If you decided to abuse a bug - it's your problem and your problem alone. The earlier you start getting rid of that design, the easier it will be when the bug gets inevitable fixed.

-- 
Bye,
Gor Gyolchanyan.


July 15, 2012
On Sun, Jul 15, 2012 at 1:41 PM, Benjamin Thaut <code@benjamin-thaut.de>wrote:

> Am 15.07.2012 02:02, schrieb Timon Gehr:
>
>  On 07/15/2012 12:55 AM, Benjamin Thaut wrote:
>>
>>> Am 14.07.2012 19:30, schrieb Gor Gyolchanyan:
>>>
>>>> On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut <code@benjamin-thaut.de <mailto:code@benjamin-thaut.de**>> wrote:
>>>>
>>>> Am 14.07.2012 19:21, schrieb kenji hara:
>>>>
>>>> 2012/7/15 Benjamin Thaut <code@benjamin-thaut.de <mailto:code@benjamin-thaut.de**>>:
>>>>
>>>> The only problem about this is:
>>>>
>>>> class Fruit
>>>> {
>>>> class Seed {
>>>> void SetFruit(Fruit fruit)
>>>> {
>>>> this.outer = fruit;
>>>>
>>>>
>>>> Setting to pseudo variable 'outer' should be rejected in
>>>> compilation.
>>>> Please report it to bugzilla.
>>>>
>>>> }
>>>> }
>>>> }
>>>>
>>>> class Apple: Fruit
>>>> {
>>>> void AppleOnlyMethod(){ ... }
>>>>
>>>> class AppleSeed: Fruit.Seed {
>>>> void DoSomething()
>>>> {
>>>> AppleOnlyMethod();
>>>> }
>>>> }
>>>>
>>>> auto GetNewSeed() { return new AppleSeed(); }
>>>> }
>>>>
>>>> auto apple = new Apple();
>>>> auto seed = apple.GetNewSeed();
>>>> seed.SetFruit(new Fruit());
>>>> seed.DoSomething(); //what happens here?
>>>>
>>>> Kind Regards
>>>> Benjamin Thaut
>>>>
>>>>
>>>> Kenji Hara
>>>>
>>>>
>>>> I will not report this, beacuse it will break my custom new operator
>>>> (template) for inner classes ;-)
>>>>
>>>> Kind Regards
>>>> Benjamin Thaut
>>>>
>>>>
>>>> That's most unwise, because if it's not supposed to be like that it will get fixed anyway, so you better start replacing your custom new operator.
>>>>
>>>> --
>>>> Bye,
>>>> Gor Gyolchanyan.
>>>>
>>>
>>> Replacing my custom new operator exactly by what? Overloading the build in new is deprecated...
>>>
>>>
>> class C{
>>      class D{
>>
>>      }
>> }
>> void main(){
>>      auto c = new C;
>>      auto buf = new void[__traits(**classInstanceSize, C.D)];
>>      (cast(byte[])buf)[] = typeid(C.D).init[];
>>      auto d = cast(C.D)buf.ptr;
>>      static if(is(typeof(d.__ctor()))) d.__ctor();
>>      enum offset=d.outer.offsetof;
>>      static assert(offset%C.sizeof==0);
>>      (cast(C[])buf)[offset/C.**sizeof]=c;
>>      assert(d.outer is c);
>> }
>>
>
> Yes of course I can assign the reference by computing the address and then using that to assign it. But the point here is, that this is currently the only bug that is hepling me in what I'm doing, and I rather want the 7 other bugs I reported so far to be fixed, rather then the one that helps me.
>
> Kind Regards
> Benjamin Thaut
>
>
Not being able to assign is not about some sort of authoritative forbidding. It's about not breaking a working mechanism. You can't cast a function pointer into a class object not because the type system says so (which it does), but because that'll result in an undefined behavior, which will result in an immediate crash in the best scenario. Go ahead and change the outer via those hacks. But then don't get surprised when your program crashes for no reason (because the compiler assumed it not to change and ended up being wrong).

-- 
Bye,
Gor Gyolchanyan.


July 15, 2012
Am 15.07.2012 13:24, schrieb Gor Gyolchanyan:
> On Sun, Jul 15, 2012 at 1:41 PM, Benjamin Thaut <code@benjamin-thaut.de
> <mailto:code@benjamin-thaut.de>> wrote:
>
>     Am 15.07.2012 02:02, schrieb Timon Gehr:
>
>         On 07/15/2012 12:55 AM, Benjamin Thaut wrote:
>
>             Am 14.07.2012 19:30, schrieb Gor Gyolchanyan:
>
>                 On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut
>                 <code@benjamin-thaut.de <mailto:code@benjamin-thaut.de>
>                 <mailto:code@benjamin-thaut.de
>                 <mailto:code@benjamin-thaut.de>__>> wrote:
>
>                 Am 14.07.2012 19:21, schrieb kenji hara:
>
>                 2012/7/15 Benjamin Thaut <code@benjamin-thaut.de
>                 <mailto:code@benjamin-thaut.de>
>                 <mailto:code@benjamin-thaut.de
>                 <mailto:code@benjamin-thaut.de>__>>:
>
>                 The only problem about this is:
>
>                 class Fruit
>                 {
>                 class Seed {
>                 void SetFruit(Fruit fruit)
>                 {
>                 this.outer = fruit;
>
>
>                 Setting to pseudo variable 'outer' should be rejected in
>                 compilation.
>                 Please report it to bugzilla.
>
>                 }
>                 }
>                 }
>
>                 class Apple: Fruit
>                 {
>                 void AppleOnlyMethod(){ ... }
>
>                 class AppleSeed: Fruit.Seed {
>                 void DoSomething()
>                 {
>                 AppleOnlyMethod();
>                 }
>                 }
>
>                 auto GetNewSeed() { return new AppleSeed(); }
>                 }
>
>                 auto apple = new Apple();
>                 auto seed = apple.GetNewSeed();
>                 seed.SetFruit(new Fruit());
>                 seed.DoSomething(); //what happens here?
>
>                 Kind Regards
>                 Benjamin Thaut
>
>
>                 Kenji Hara
>
>
>                 I will not report this, beacuse it will break my custom
>                 new operator
>                 (template) for inner classes ;-)
>
>                 Kind Regards
>                 Benjamin Thaut
>
>
>                 That's most unwise, because if it's not supposed to be
>                 like that it will
>                 get fixed anyway, so you better start replacing your
>                 custom new
>                 operator.
>
>                 --
>                 Bye,
>                 Gor Gyolchanyan.
>
>
>             Replacing my custom new operator exactly by what?
>             Overloading the build
>             in new is deprecated...
>
>
>         class C{
>               class D{
>
>               }
>         }
>         void main(){
>               auto c = new C;
>               auto buf = new void[__traits(__classInstanceSize, C.D)];
>               (cast(byte[])buf)[] = typeid(C.D).init[];
>               auto d = cast(C.D)buf.ptr;
>               static if(is(typeof(d.__ctor()))) d.__ctor();
>               enum offset=d.outer.offsetof;
>               static assert(offset%C.sizeof==0);
>               (cast(C[])buf)[offset/C.__sizeof]=c;
>               assert(d.outer is c);
>         }
>
>
>     Yes of course I can assign the reference by computing the address
>     and then using that to assign it. But the point here is, that this
>     is currently the only bug that is hepling me in what I'm doing, and
>     I rather want the 7 other bugs I reported so far to be fixed, rather
>     then the one that helps me.
>
>     Kind Regards
>     Benjamin Thaut
>
>
> Not being able to assign is not about some sort of authoritative
> forbidding. It's about not breaking a working mechanism. You can't cast
> a function pointer into a class object not because the type system says
> so (which it does), but because that'll result in an undefined behavior,
> which will result in an immediate crash in the best scenario. Go ahead
> and change the outer via those hacks. But then don't get surprised when
> your program crashes for no reason (because the compiler assumed it not
> to change and ended up being wrong).
>
> --
> Bye,
> Gor Gyolchanyan.

Before your change suggestion it was absolutley save to assign to outer. Thats the whole point why I posted this here. I very well know that the bug will get fixed some time. But before your change suggestion it was not even a bug.

Kind Regards
Benjamin Thaut

July 15, 2012
On Sun, Jul 15, 2012 at 3:35 PM, Benjamin Thaut <code@benjamin-thaut.de>wrote:

> Am 15.07.2012 13:24, schrieb Gor Gyolchanyan:
>
>> On Sun, Jul 15, 2012 at 1:41 PM, Benjamin Thaut <code@benjamin-thaut.de
>>
>> <mailto:code@benjamin-thaut.de**>> wrote:
>>
>>     Am 15.07.2012 02:02, schrieb Timon Gehr:
>>
>>         On 07/15/2012 12:55 AM, Benjamin Thaut wrote:
>>
>>             Am 14.07.2012 19:30, schrieb Gor Gyolchanyan:
>>
>>                 On Sat, Jul 14, 2012 at 9:23 PM, Benjamin Thaut
>>                 <code@benjamin-thaut.de <mailto:code@benjamin-thaut.de**>
>>                 <mailto:code@benjamin-thaut.de
>>
>>                 <mailto:code@benjamin-thaut.de**>__>> wrote:
>>
>>                 Am 14.07.2012 19:21, schrieb kenji hara:
>>
>>                 2012/7/15 Benjamin Thaut <code@benjamin-thaut.de
>>                 <mailto:code@benjamin-thaut.de**>
>>                 <mailto:code@benjamin-thaut.de
>>                 <mailto:code@benjamin-thaut.de**>__>>:
>>
>>
>>                 The only problem about this is:
>>
>>                 class Fruit
>>                 {
>>                 class Seed {
>>                 void SetFruit(Fruit fruit)
>>                 {
>>                 this.outer = fruit;
>>
>>
>>                 Setting to pseudo variable 'outer' should be rejected in
>>                 compilation.
>>                 Please report it to bugzilla.
>>
>>                 }
>>                 }
>>                 }
>>
>>                 class Apple: Fruit
>>                 {
>>                 void AppleOnlyMethod(){ ... }
>>
>>                 class AppleSeed: Fruit.Seed {
>>                 void DoSomething()
>>                 {
>>                 AppleOnlyMethod();
>>                 }
>>                 }
>>
>>                 auto GetNewSeed() { return new AppleSeed(); }
>>                 }
>>
>>                 auto apple = new Apple();
>>                 auto seed = apple.GetNewSeed();
>>                 seed.SetFruit(new Fruit());
>>                 seed.DoSomething(); //what happens here?
>>
>>                 Kind Regards
>>                 Benjamin Thaut
>>
>>
>>                 Kenji Hara
>>
>>
>>                 I will not report this, beacuse it will break my custom
>>                 new operator
>>                 (template) for inner classes ;-)
>>
>>                 Kind Regards
>>                 Benjamin Thaut
>>
>>
>>                 That's most unwise, because if it's not supposed to be
>>                 like that it will
>>                 get fixed anyway, so you better start replacing your
>>                 custom new
>>                 operator.
>>
>>                 --
>>                 Bye,
>>                 Gor Gyolchanyan.
>>
>>
>>             Replacing my custom new operator exactly by what?
>>             Overloading the build
>>             in new is deprecated...
>>
>>
>>         class C{
>>               class D{
>>
>>               }
>>         }
>>         void main(){
>>               auto c = new C;
>>               auto buf = new void[__traits(__**classInstanceSize, C.D)];
>>
>>               (cast(byte[])buf)[] = typeid(C.D).init[];
>>               auto d = cast(C.D)buf.ptr;
>>               static if(is(typeof(d.__ctor()))) d.__ctor();
>>               enum offset=d.outer.offsetof;
>>               static assert(offset%C.sizeof==0);
>>               (cast(C[])buf)[offset/C.__**sizeof]=c;
>>
>>               assert(d.outer is c);
>>         }
>>
>>
>>     Yes of course I can assign the reference by computing the address
>>     and then using that to assign it. But the point here is, that this
>>     is currently the only bug that is hepling me in what I'm doing, and
>>     I rather want the 7 other bugs I reported so far to be fixed, rather
>>     then the one that helps me.
>>
>>     Kind Regards
>>     Benjamin Thaut
>>
>>
>> Not being able to assign is not about some sort of authoritative forbidding. It's about not breaking a working mechanism. You can't cast a function pointer into a class object not because the type system says so (which it does), but because that'll result in an undefined behavior, which will result in an immediate crash in the best scenario. Go ahead and change the outer via those hacks. But then don't get surprised when your program crashes for no reason (because the compiler assumed it not to change and ended up being wrong).
>>
>> --
>> Bye,
>> Gor Gyolchanyan.
>>
>
> Before your change suggestion it was absolutley save to assign to outer. Thats the whole point why I posted this here. I very well know that the bug will get fixed some time. But before your change suggestion it was not even a bug.
>
> Kind Regards
> Benjamin Thaut
>
>
A bug remains a bug whether it was discovered or not. If it wasn't - it would never get discovered. Even if the bug didn't get discovered for a long time, making designs around bugs is a very bad idea precisely for this reason. But it's not entirely your fault, because there's no reliable reference to D at the moment, so it's very hard to determine what is and is not supposed to work. That's one of the problems, that drive new commers away: lack of a reference material.

-- 
Bye,
Gor Gyolchanyan.


1 2 3 4 5 6
Next ›   Last »