Jump to page: 1 2
Thread overview
[dmd-beta] dmd 1.065 and 2.050 beta
Oct 27, 2010
Stephan Dilly
Oct 27, 2010
Stephan Dilly
Oct 27, 2010
Don Clugston
Oct 27, 2010
Stephan Dilly
Oct 27, 2010
Don Clugston
Oct 27, 2010
Walter Bright
Oct 27, 2010
Sönke Ludwig
Oct 27, 2010
David Simcha
Oct 27, 2010
Sönke Ludwig
Oct 27, 2010
David Simcha
Oct 27, 2010
Jonathan M Davis
Oct 28, 2010
David Simcha
Oct 28, 2010
Jonathan M Davis
Oct 28, 2010
Jonathan M Davis
Oct 28, 2010
David Simcha
Oct 28, 2010
Jonathan M Davis
October 27, 2010
> http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip

1) the client still says it is version 2.049

2) there seems to be a regression with pure opCall methods introduced. The following code used to build with dmd2049 but now does not:


struct Foo
{
     static Foo opCall(in Foo _f) pure
     {
         return Foo;
     }
}

instead the compiler issues the following error:
"Error: struct bug.Foo no size yet for forward reference"

the workaround would be to remove the pure but that is no option for my codebase full of pure opCalls.


regards,
     Stephan
October 27, 2010
On 27.10.2010 14:51, Stephan Dilly wrote:
>> http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip
>
> 1) the client still says it is version 2.049
>
> 2) there seems to be a regression with pure opCall methods introduced. The following code used to build with dmd2049 but now does not:
>
>
> struct Foo
> {
>     static Foo opCall(in Foo _f) pure
>     {
>         return Foo;
>     }
> }
>
> instead the compiler issues the following error:
> "Error: struct bug.Foo no size yet for forward reference"
>
> the workaround would be to remove the pure but that is no option for my codebase full of pure opCalls.
>
>
> regards,
>     Stephan

Ok to be fair, this is the correct code that works in dmd2049 and does not in the beta:

struct Foo
{
     static Foo opCall(in Foo _f) pure
     {
         return _f;
     }
}

October 27, 2010
On 27 October 2010 15:29, Stephan Dilly <Dilly at funatics.de> wrote:
> On 27.10.2010 14:51, Stephan Dilly wrote:
>>>
>>> http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip
>>
>> 1) the client still says it is version 2.049
>>
>> 2) there seems to be a regression with pure opCall methods introduced. The following code used to build with dmd2049 but now does not:
>>
>>
>> struct Foo
>> {
>> ? ?static Foo opCall(in Foo _f) pure
>> ? ?{
>> ? ? ? ?return Foo;
>> ? ?}
>> }
>>
>> instead the compiler issues the following error:
>> "Error: struct bug.Foo no size yet for forward reference"
>>
>> the workaround would be to remove the pure but that is no option for my codebase full of pure opCalls.
>>
>>
>> regards,
>> ? ?Stephan
>
> Ok to be fair, this is the correct code that works in dmd2049 and does not in the beta:
>
> struct Foo
> {
> ? ?static Foo opCall(in Foo _f) pure
> ? ?{
> ? ? ? ?return _f;
> ? ?}
> }

That is happening because in mtype.c, line 5013, it's trying to work
out which form of purity the function is. It can't do this for a
struct, until it knows if the struct has any pointer members. This is
a problem if it's a member function.
I don't know if it really needs to determine purity level so early on.
October 27, 2010
On 27.10.2010 16:14, Don Clugston wrote:
> On 27 October 2010 15:29, Stephan Dilly<Dilly at funatics.de>  wrote:
>> On 27.10.2010 14:51, Stephan Dilly wrote:
>>>> http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip
>>> 1) the client still says it is version 2.049
>>>
>>> 2) there seems to be a regression with pure opCall methods introduced. The following code used to build with dmd2049 but now does not:
>>>
>>>
>>> struct Foo
>>> {
>>>     static Foo opCall(in Foo _f) pure
>>>     {
>>>         return Foo;
>>>     }
>>> }
>>>
>>> instead the compiler issues the following error:
>>> "Error: struct bug.Foo no size yet for forward reference"
>>>
>>> the workaround would be to remove the pure but that is no option for my codebase full of pure opCalls.
>>>
>>>
>>> regards,
>>>     Stephan
>> Ok to be fair, this is the correct code that works in dmd2049 and does not in the beta:
>>
>> struct Foo
>> {
>>     static Foo opCall(in Foo _f) pure
>>     {
>>         return _f;
>>     }
>> }
> That is happening because in mtype.c, line 5013, it's trying to work
> out which form of purity the function is. It can't do this for a
> struct, until it knows if the struct has any pointer members. This is
> a problem if it's a member function.
> I don't know if it really needs to determine purity level so early on.
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

I don't know either ;)
Does that mean that static pure opCalls wont be possible from now on ?
If this is not a regression but a "feature" i want to know as soon as
possible, so i can start converting the whole freakin codebase.
October 27, 2010
On 27 October 2010 16:50, Stephan Dilly <Dilly at funatics.de> wrote:
> On 27.10.2010 16:14, Don Clugston wrote:
>>
>> On 27 October 2010 15:29, Stephan Dilly<Dilly at funatics.de> ?wrote:
>>>
>>> On 27.10.2010 14:51, Stephan Dilly wrote:
>>>>>
>>>>> http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip
>>>>
>>>> 1) the client still says it is version 2.049
>>>>
>>>> 2) there seems to be a regression with pure opCall methods introduced.
>>>> The
>>>> following code used to build with dmd2049 but now does not:
>>>>
>>>>
>>>> struct Foo
>>>> {
>>>> ? ?static Foo opCall(in Foo _f) pure
>>>> ? ?{
>>>> ? ? ? ?return Foo;
>>>> ? ?}
>>>> }
>>>>
>>>> instead the compiler issues the following error:
>>>> "Error: struct bug.Foo no size yet for forward reference"
>>>>
>>>> the workaround would be to remove the pure but that is no option for my codebase full of pure opCalls.
>>>>
>>>>
>>>> regards,
>>>> ? ?Stephan
>>>
>>> Ok to be fair, this is the correct code that works in dmd2049 and does
>>> not
>>> in the beta:
>>>
>>> struct Foo
>>> {
>>> ? ?static Foo opCall(in Foo _f) pure
>>> ? ?{
>>> ? ? ? ?return _f;
>>> ? ?}
>>> }
>>
>> That is happening because in mtype.c, line 5013, it's trying to work
>> out which form of purity the function is. It can't do this for a
>> struct, until it knows if the struct has any pointer members. This is
>> a problem if it's a member function.
>> I don't know if it really needs to determine purity level so early on.
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
>
> I don't know either ;)
> Does that mean that static pure opCalls wont be possible from now on ?

Your code should continue to work. It's a regression.
October 27, 2010
Fix is uploaded.

Don Clugston wrote:
> On 27 October 2010 16:50, Stephan Dilly <Dilly at funatics.de> wrote:
> 
>> On 27.10.2010 16:14, Don Clugston wrote:
>> 
>>> On 27 October 2010 15:29, Stephan Dilly<Dilly at funatics.de>  wrote:
>>> 
>>>> On 27.10.2010 14:51, Stephan Dilly wrote:
>>>> 
>>>>>> http://ftp.digitalmars.com/dmd1beta.zip
>>>>>> http://ftp.digitalmars.com/dmd2beta.zip
>>>>>> 
>>>>> 1) the client still says it is version 2.049
>>>>>
>>>>> 2) there seems to be a regression with pure opCall methods introduced.
>>>>> The
>>>>> following code used to build with dmd2049 but now does not:
>>>>>
>>>>>
>>>>> struct Foo
>>>>> {
>>>>>    static Foo opCall(in Foo _f) pure
>>>>>    {
>>>>>        return Foo;
>>>>>    }
>>>>> }
>>>>>
>>>>> instead the compiler issues the following error:
>>>>> "Error: struct bug.Foo no size yet for forward reference"
>>>>>
>>>>> the workaround would be to remove the pure but that is no option for my codebase full of pure opCalls.
>>>>>
>>>>>
>>>>> regards,
>>>>>    Stephan
>>>>> 
>>>> Ok to be fair, this is the correct code that works in dmd2049 and does
>>>> not
>>>> in the beta:
>>>>
>>>> struct Foo
>>>> {
>>>>    static Foo opCall(in Foo _f) pure
>>>>    {
>>>>        return _f;
>>>>    }
>>>> }
>>>> 
>>> That is happening because in mtype.c, line 5013, it's trying to work
>>> out which form of purity the function is. It can't do this for a
>>> struct, until it knows if the struct has any pointer members. This is
>>> a problem if it's a member function.
>>> I don't know if it really needs to determine purity level so early on.
>>> _______________________________________________
>>> dmd-beta mailing list
>>> dmd-beta at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>>
>>> 
>> I don't know either ;)
>> Does that mean that static pure opCalls wont be possible from now on ?
>> 
>
> Your code should continue to work. It's a regression.
>
> 
October 27, 2010
  There seems to be a regression in std.algorithm.startsWith. With 2.049
this still worked:

invariant string s = "Hello, World!";
bool res = s.startsWith("Hello");

now the template cannot be matched anymore. Remove the invariant and it works.

Am 27.10.2010 21:13, schrieb Walter Bright:
> Fix is uploaded.
>
> Don Clugston wrote:
>> On 27 October 2010 16:50, Stephan Dilly <Dilly at funatics.de> wrote:
>>> On 27.10.2010 16:14, Don Clugston wrote:
>>>> On 27 October 2010 15:29, Stephan Dilly<Dilly at funatics.de>  wrote:
>>>>> On 27.10.2010 14:51, Stephan Dilly wrote:
>>>>>>> http://ftp.digitalmars.com/dmd1beta.zip http://ftp.digitalmars.com/dmd2beta.zip
>>>>>> 1) the client still says it is version 2.049
>>>>>>
>>>>>> 2) there seems to be a regression with pure opCall methods
>>>>>> introduced.
>>>>>> The
>>>>>> following code used to build with dmd2049 but now does not:
>>>>>>
>>>>>>
>>>>>> struct Foo
>>>>>> {
>>>>>>    static Foo opCall(in Foo _f) pure
>>>>>>    {
>>>>>>        return Foo;
>>>>>>    }
>>>>>> }
>>>>>>
>>>>>> instead the compiler issues the following error:
>>>>>> "Error: struct bug.Foo no size yet for forward reference"
>>>>>>
>>>>>> the workaround would be to remove the pure but that is no option
>>>>>> for my
>>>>>> codebase full of pure opCalls.
>>>>>>
>>>>>>
>>>>>> regards,
>>>>>>    Stephan
>>>>> Ok to be fair, this is the correct code that works in dmd2049 and
>>>>> does
>>>>> not
>>>>> in the beta:
>>>>>
>>>>> struct Foo
>>>>> {
>>>>>    static Foo opCall(in Foo _f) pure
>>>>>    {
>>>>>        return _f;
>>>>>    }
>>>>> }
>>>> That is happening because in mtype.c, line 5013, it's trying to work
>>>> out which form of purity the function is. It can't do this for a
>>>> struct, until it knows if the struct has any pointer members. This is
>>>> a problem if it's a member function.
>>>> I don't know if it really needs to determine purity level so early on.
>>>> _______________________________________________
>>>> dmd-beta mailing list
>>>> dmd-beta at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>>>
>>> I don't know either ;)
>>> Does that mean that static pure opCalls wont be possible from now on ?
>>
>> Your code should continue to work. It's a regression.
>>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

October 27, 2010
This is not a regression.  The example code you posted was never supposed to work, but relied on bugs in DMD to work nonetheless.  An immutable(char[]) is not an input range since you can't call popFront() on it.  You used to be able to because of Bug 3534 ( http://d.puremagic.com/issues/show_bug.cgi?id=3534).  I added code to Phobos to explicitly disable this, so that until 3534 gets fixed people avoid writing code that relies on it.

On Wed, Oct 27, 2010 at 3:47 PM, S?nke Ludwig <
ludwig at informatik.uni-luebeck.de> wrote:

>  There seems to be a regression in std.algorithm.startsWith. With 2.049
> this still worked:
>
> invariant string s = "Hello, World!";
> bool res = s.startsWith("Hello");
>
> now the template cannot be matched anymore. Remove the invariant and it works.
>
> Am 27.10.2010 21:13, schrieb Walter Bright:
>
>  Fix is uploaded.
>>
>> Don Clugston wrote:
>>
>>> On 27 October 2010 16:50, Stephan Dilly <Dilly at funatics.de> wrote:
>>>
>>>> On 27.10.2010 16:14, Don Clugston wrote:
>>>>
>>>>> On 27 October 2010 15:29, Stephan Dilly<Dilly at funatics.de>  wrote:
>>>>>
>>>>>> On 27.10.2010 14:51, Stephan Dilly wrote:
>>>>>>
>>>>>>> http://ftp.digitalmars.com/dmd1beta.zip
>>>>>>>> http://ftp.digitalmars.com/dmd2beta.zip
>>>>>>>>
>>>>>>> 1) the client still says it is version 2.049
>>>>>>>
>>>>>>> 2) there seems to be a regression with pure opCall methods
>>>>>>> introduced.
>>>>>>> The
>>>>>>> following code used to build with dmd2049 but now does not:
>>>>>>>
>>>>>>>
>>>>>>> struct Foo
>>>>>>> {
>>>>>>>   static Foo opCall(in Foo _f) pure
>>>>>>>   {
>>>>>>>       return Foo;
>>>>>>>   }
>>>>>>> }
>>>>>>>
>>>>>>> instead the compiler issues the following error:
>>>>>>> "Error: struct bug.Foo no size yet for forward reference"
>>>>>>>
>>>>>>> the workaround would be to remove the pure but that is no option for
>>>>>>> my
>>>>>>> codebase full of pure opCalls.
>>>>>>>
>>>>>>>
>>>>>>> regards,
>>>>>>>   Stephan
>>>>>>>
>>>>>> Ok to be fair, this is the correct code that works in dmd2049 and does
>>>>>> not
>>>>>> in the beta:
>>>>>>
>>>>>> struct Foo
>>>>>> {
>>>>>>   static Foo opCall(in Foo _f) pure
>>>>>>   {
>>>>>>       return _f;
>>>>>>   }
>>>>>> }
>>>>>>
>>>>> That is happening because in mtype.c, line 5013, it's trying to work
>>>>> out which form of purity the function is. It can't do this for a
>>>>> struct, until it knows if the struct has any pointer members. This is
>>>>> a problem if it's a member function.
>>>>> I don't know if it really needs to determine purity level so early on.
>>>>> _______________________________________________
>>>>> dmd-beta mailing list
>>>>> dmd-beta at puremagic.com
>>>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>>>>
>>>>>  I don't know either ;)
>>>> Does that mean that static pure opCalls wont be possible from now on ?
>>>>
>>>
>>> Your code should continue to work. It's a regression.
>>>
>>>  _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20101027/0ecee072/attachment.html>
October 27, 2010
  Hm.. while it makes sense that technically an immutable(X[]) is not an
input range for the mentioned reason, practically it does not make sense
not to allow such arrays in functions like startsWith. Apart from the
obscure range related cause, there is no obvious reason why this should
be the case. For any non-expert D user I would expect this to be very
confusing and annoying for the rest. So well, for me looking from the
outside, this still looks like a regression although technically it
maybe is not.

Am 27.10.2010 22:58, schrieb David Simcha:
> This is not a regression.  The example code you posted was never supposed to work, but relied on bugs in DMD to work nonetheless.  An immutable(char[]) is not an input range since you can't call popFront() on it.  You used to be able to because of Bug 3534 (http://d.puremagic.com/issues/show_bug.cgi?id=3534).  I added code to Phobos to explicitly disable this, so that until 3534 gets fixed people avoid writing code that relies on it.
>
> On Wed, Oct 27, 2010 at 3:47 PM, S?nke Ludwig <ludwig at informatik.uni-luebeck.de <mailto:ludwig at informatik.uni-luebeck.de>> wrote:
>
>      There seems to be a regression in std.algorithm.startsWith. With
>     2.049 this still worked:
>
>     invariant string s = "Hello, World!";
>     bool res = s.startsWith("Hello");
>
>     now the template cannot be matched anymore. Remove the invariant
>     and it works.
>
>     Am 27.10.2010 21:13, schrieb Walter Bright:
>
>         Fix is uploaded.
>
>         Don Clugston wrote:
>
>             On 27 October 2010 16:50, Stephan Dilly <Dilly at funatics.de
>             <mailto:Dilly at funatics.de>> wrote:
>
>                 On 27.10.2010 16:14, Don Clugston wrote:
>
>                     On 27 October 2010 15:29, Stephan
>                     Dilly<Dilly at funatics.de
>                     <mailto:Dilly at funatics.de>>  wrote:
>
>                         On 27.10.2010 14:51, Stephan Dilly wrote:
>
>                                 http://ftp.digitalmars.com/dmd1beta.zip
>                                 http://ftp.digitalmars.com/dmd2beta.zip
>
>                             1) the client still says it is version 2.049
>
>                             2) there seems to be a regression with
>                             pure opCall methods introduced.
>                             The
>                             following code used to build with dmd2049
>                             but now does not:
>
>
>                             struct Foo
>                             {
>                               static Foo opCall(in Foo _f) pure
>                               {
>                                   return Foo;
>                               }
>                             }
>
>                             instead the compiler issues the following
>                             error:
>                             "Error: struct bug.Foo no size yet for
>                             forward reference"
>
>                             the workaround would be to remove the pure
>                             but that is no option for my
>                             codebase full of pure opCalls.
>
>
>                             regards,
>                               Stephan
>
>                         Ok to be fair, this is the correct code that
>                         works in dmd2049 and does
>                         not
>                         in the beta:
>
>                         struct Foo
>                         {
>                           static Foo opCall(in Foo _f) pure
>                           {
>                               return _f;
>                           }
>                         }
>
>                     That is happening because in mtype.c, line 5013,
>                     it's trying to work
>                     out which form of purity the function is. It can't
>                     do this for a
>                     struct, until it knows if the struct has any
>                     pointer members. This is
>                     a problem if it's a member function.
>                     I don't know if it really needs to determine
>                     purity level so early on.
>                     _______________________________________________
>                     dmd-beta mailing list
>                     dmd-beta at puremagic.com <mailto:dmd-beta at puremagic.com>
>                     http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>                 I don't know either ;)
>                 Does that mean that static pure opCalls wont be
>                 possible from now on ?
>
>
>             Your code should continue to work. It's a regression.
>
>         _______________________________________________
>         dmd-beta mailing list
>         dmd-beta at puremagic.com <mailto:dmd-beta at puremagic.com>
>         http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>
>     _______________________________________________
>     dmd-beta mailing list
>     dmd-beta at puremagic.com <mailto:dmd-beta at puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20101027/226d1729/attachment.html>
October 27, 2010
I agree 100% that startsWith needs to work with immutable(X[]). Nonetheless, the proper way to address this is by fixing the language, not by relying on expedient bugs.  I insisted on fixing this because history has shown that if too many people start relying on behavior that is clearly a bug but happens to be expedient, the bug becomes politically unfixable no matter how wrong the behavior is.  Fixing the rest of Phobos such that startsWith() and similar functions will work with immutable(X[]) without relying on Bug 3534 would have been a monumental task (I tried).

My proposal for dealing with this issue has always been that IFTI should instantiate a function with an Unqual!(T) when passed a T, if and only if the given T is implicitly convertible to Unqual!(T).  For example:

void foo(T)(T arg) {}

immutable str = "A family of foxes found food in the forest.";
foo(str);  // Equivalent to foo!(immutable(char)[])(str);

immutable num = 2;
foo(num);  // Equivalent to foo!(int)(num);

const myRetro = retro([1,2,3,4,5,6]);
foo(myRetro);  // const(Retro!(int[])) doesn't implicitly convert to
               // Unqual!(const(Retro!(int[]))).  No Unqual applied.


On Wed, Oct 27, 2010 at 5:25 PM, S?nke Ludwig <
ludwig at informatik.uni-luebeck.de> wrote:

>  Hm.. while it makes sense that technically an immutable(X[]) is not an
> input range for the mentioned reason, practically it does not make sense not
> to allow such arrays in functions like startsWith. Apart from the obscure
> range related cause, there is no obvious reason why this should be the case.
> For any non-expert D user I would expect this to be very confusing and
> annoying for the rest. So well, for me looking from the outside, this still
> looks like a regression although technically it maybe is not.
>
> Am 27.10.2010 22:58, schrieb David Simcha:
>
> This is not a regression.  The example code you posted was never supposed to work, but relied on bugs in DMD to work nonetheless.  An immutable(char[]) is not an input range since you can't call popFront() on it.  You used to be able to because of Bug 3534 ( http://d.puremagic.com/issues/show_bug.cgi?id=3534).  I added code to Phobos to explicitly disable this, so that until 3534 gets fixed people avoid writing code that relies on it.
>
> On Wed, Oct 27, 2010 at 3:47 PM, S?nke Ludwig <
> ludwig at informatik.uni-luebeck.de> wrote:
>
>>  There seems to be a regression in std.algorithm.startsWith. With 2.049
>> this still worked:
>>
>> invariant string s = "Hello, World!";
>> bool res = s.startsWith("Hello");
>>
>> now the template cannot be matched anymore. Remove the invariant and it works.
>>
>> Am 27.10.2010 21:13, schrieb Walter Bright:
>>
>>  Fix is uploaded.
>>>
>>> Don Clugston wrote:
>>>
>>>> On 27 October 2010 16:50, Stephan Dilly <Dilly at funatics.de> wrote:
>>>>
>>>>> On 27.10.2010 16:14, Don Clugston wrote:
>>>>>
>>>>>> On 27 October 2010 15:29, Stephan Dilly<Dilly at funatics.de>  wrote:
>>>>>>
>>>>>>> On 27.10.2010 14:51, Stephan Dilly wrote:
>>>>>>>
>>>>>>>>  http://ftp.digitalmars.com/dmd1beta.zip
>>>>>>>>> http://ftp.digitalmars.com/dmd2beta.zip
>>>>>>>>>
>>>>>>>> 1) the client still says it is version 2.049
>>>>>>>>
>>>>>>>> 2) there seems to be a regression with pure opCall methods
>>>>>>>> introduced.
>>>>>>>> The
>>>>>>>> following code used to build with dmd2049 but now does not:
>>>>>>>>
>>>>>>>>
>>>>>>>> struct Foo
>>>>>>>> {
>>>>>>>>   static Foo opCall(in Foo _f) pure
>>>>>>>>   {
>>>>>>>>       return Foo;
>>>>>>>>   }
>>>>>>>> }
>>>>>>>>
>>>>>>>> instead the compiler issues the following error:
>>>>>>>> "Error: struct bug.Foo no size yet for forward reference"
>>>>>>>>
>>>>>>>> the workaround would be to remove the pure but that is no option for
>>>>>>>> my
>>>>>>>> codebase full of pure opCalls.
>>>>>>>>
>>>>>>>>
>>>>>>>> regards,
>>>>>>>>   Stephan
>>>>>>>>
>>>>>>> Ok to be fair, this is the correct code that works in dmd2049 and
>>>>>>> does
>>>>>>> not
>>>>>>> in the beta:
>>>>>>>
>>>>>>> struct Foo
>>>>>>> {
>>>>>>>   static Foo opCall(in Foo _f) pure
>>>>>>>   {
>>>>>>>       return _f;
>>>>>>>   }
>>>>>>> }
>>>>>>>
>>>>>> That is happening because in mtype.c, line 5013, it's trying to work
>>>>>> out which form of purity the function is. It can't do this for a
>>>>>> struct, until it knows if the struct has any pointer members. This is
>>>>>> a problem if it's a member function.
>>>>>> I don't know if it really needs to determine purity level so early on.
>>>>>> _______________________________________________
>>>>>> dmd-beta mailing list
>>>>>> dmd-beta at puremagic.com
>>>>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>>>>>
>>>>>>  I don't know either ;)
>>>>> Does that mean that static pure opCalls wont be possible from now on ?
>>>>>
>>>>
>>>> Your code should continue to work. It's a regression.
>>>>
>>>>  _______________________________________________
>>> dmd-beta mailing list
>>> dmd-beta at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>>
>>
>> _______________________________________________
>> dmd-beta mailing list
>> dmd-beta at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
>
>
> _______________________________________________
> dmd-beta mailing listdmd-beta at puremagic.comhttp://lists.puremagic.com/mailman/listinfo/dmd-beta
>
>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20101027/9b55cef6/attachment-0001.html>
« First   ‹ Prev
1 2