www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - UFCS in the presence of alias this

reply Jens Mueller <jens.k.mueller gmx.de> writes:
Hi,

using UFCS with alias this behaves strange.
Consider

struct Foo
{
    int _member;
    alias _member this;
}

int foo(Foo f) { return f._member; }
int foo(int i) { return i; }

unittest
{
    Foo f;
    f.foo(); // which function will be called? Isn't it ambiguous?
}

Due to the alias this the function foo(int i) will be called. Is this
the indented behavior? Practically, I want UFCS to just perform a
syntactic rewrite from f.foo() to foo(f).
When using alias this you have to define the second function. Providing
only the first one results in a compile error. If you remove the alias
this things work as expected (first one needs to be defined).

I stumbled upon this problem when trying to define additional functions
for a Tuple. Tuple has "alias field this" for falling back on
TypeTuple's opIndex. Unfortunately,

alias Tuple!(int) Bar;
int bar(typeof(Bar.field) b) { return 1; }

unittest
{
    Bar b;
    b.bar();
}

does not work.

Jens
Apr 19 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/19/2012 11:28 AM, Jens Mueller wrote:

 Hi,

 using UFCS with alias this behaves strange.
 Consider

 struct Foo
 {
      int _member;
      alias _member this;
 }

 int foo(Foo f) { return f._member; }
 int foo(int i) { return i; }

 unittest
 {
      Foo f;
      f.foo(); // which function will be called? Isn't it ambiguous?
 }

 Due to the alias this the function foo(int i) will be called. Is this
 the indented behavior? Practically, I want UFCS to just perform a
 syntactic rewrite from f.foo() to foo(f).
 When using alias this you have to define the second function. Providing
 only the first one results in a compile error. If you remove the alias
 this things work as expected (first one needs to be defined).

 I stumbled upon this problem when trying to define additional functions
 for a Tuple. Tuple has "alias field this" for falling back on
 TypeTuple's opIndex. Unfortunately,

 alias Tuple!(int) Bar;
 int bar(typeof(Bar.field) b) { return 1; }

 unittest
 {
      Bar b;
      b.bar();
 }

 does not work.

 Jens



This is a bug. You can report it to:
http://d.puremagic.com/issues/
Apr 19 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/19/2012 05:56 PM, Philippe Sigaud wrote:

 Jens:

 It's submitted.
 http://d.puremagic.com/issues/show_bug.cgi?id=7943






 (something like, one hour passes)



I counted 26 minutes.


 Kenji:

 Posted compiler fix:
 https://github.com/D-Programming-Language/dmd/pull/890



 Man, you're wonderful Kenji. You never cease to amaze me. Your ability
 to correct bugs is borderline incredible.
Apr 19 2012
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
Timon Gehr wrote:

 On 04/19/2012 11:28 AM, Jens Mueller wrote:

Hi,

using UFCS with alias this behaves strange.
Consider

struct Foo
{
     int _member;
     alias _member this;
}

int foo(Foo f) { return f._member; }
int foo(int i) { return i; }

unittest
{
     Foo f;
     f.foo(); // which function will be called? Isn't it ambiguous?
}

Due to the alias this the function foo(int i) will be called. Is this
the indented behavior? Practically, I want UFCS to just perform a
syntactic rewrite from f.foo() to foo(f).
When using alias this you have to define the second function. Providing
only the first one results in a compile error. If you remove the alias
this things work as expected (first one needs to be defined).

I stumbled upon this problem when trying to define additional functions
for a Tuple. Tuple has "alias field this" for falling back on
TypeTuple's opIndex. Unfortunately,

alias Tuple!(int) Bar;
int bar(typeof(Bar.field) b) { return 1; }

unittest
{
     Bar b;
     b.bar();
}

does not work.

Jens



 This is a bug. You can report it to:
 http://d.puremagic.com/issues/



It's submitted.
http://d.puremagic.com/issues/show_bug.cgi?id=7943
Thanks for your reply.

Jens
Apr 19 2012
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
2012年4月19日20:48 Jens Mueller <jens.k.mueller gmx.de>:

 Timon Gehr wrote:

 On 04/19/2012 11:28 AM, Jens Mueller wrote:

Hi,

using UFCS with alias this behaves strange.
Consider

struct Foo
{
     int _member;
     alias _member this;
}

int foo(Foo f) { return f._member; }
int foo(int i) { return i; }

unittest
{
     Foo f;
     f.foo(); // which function will be called? Isn't it ambiguous?
}

Due to the alias this the function foo(int i) will be called. Is this
the indented behavior? Practically, I want UFCS to just perform a
syntactic rewrite from f.foo() to foo(f).
When using alias this you have to define the second function. Providing
only the first one results in a compile error. If you remove the alias
this things work as expected (first one needs to be defined).

I stumbled upon this problem when trying to define additional functions
for a Tuple. Tuple has "alias field this" for falling back on
TypeTuple's opIndex. Unfortunately,

alias Tuple!(int) Bar;
int bar(typeof(Bar.field) b) { return 1; }

unittest
{
     Bar b;
     b.bar();
}

does not work.

Jens



 This is a bug. You can report it to:
 http://d.puremagic.com/issues/



 It's submitted.
 http://d.puremagic.com/issues/show_bug.cgi?id=7943
 Thanks for your reply.

 Jens



Posted compiler fix:
https://github.com/D-Programming-Language/dmd/pull/890

Thanks for your reporting, Jens!

Kenji Hara
Apr 19 2012
prev sibling next sibling parent Jens Mueller <jens.k.mueller gmx.de> writes:
kenji hara wrote:

 2012年4月19日20:48 Jens Mueller <jens.k.mueller gmx.de>:

 Timon Gehr wrote:

 On 04/19/2012 11:28 AM, Jens Mueller wrote:

Hi,

using UFCS with alias this behaves strange.
Consider

struct Foo
{
     int _member;
     alias _member this;
}

int foo(Foo f) { return f._member; }
int foo(int i) { return i; }

unittest
{
     Foo f;
     f.foo(); // which function will be called? Isn't it ambiguous?
}

Due to the alias this the function foo(int i) will be called. Is this
the indented behavior? Practically, I want UFCS to just perform a
syntactic rewrite from f.foo() to foo(f).
When using alias this you have to define the second function. Providing
only the first one results in a compile error. If you remove the alias
this things work as expected (first one needs to be defined).

I stumbled upon this problem when trying to define additional functions
for a Tuple. Tuple has "alias field this" for falling back on
TypeTuple's opIndex. Unfortunately,

alias Tuple!(int) Bar;
int bar(typeof(Bar.field) b) { return 1; }

unittest
{
     Bar b;
     b.bar();
}

does not work.

Jens



 This is a bug. You can report it to:
 http://d.puremagic.com/issues/



 It's submitted.
 http://d.puremagic.com/issues/show_bug.cgi?id=7943
 Thanks for your reply.

 Jens



 Posted compiler fix:
 https://github.com/D-Programming-Language/dmd/pull/890
 
 Thanks for your reporting, Jens!



Fabulous. Thanks a lot.

Jens
Apr 19 2012
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
Jens:

 It's submitted.
 http://d.puremagic.com/issues/show_bug.cgi?id=7943






(something like, one hour passes)

Kenji:

 Posted compiler fix:
 https://github.com/D-Programming-Language/dmd/pull/890



Man, you're wonderful Kenji. You never cease to amaze me. Your ability
to correct bugs is borderline incredible.
Apr 19 2012
prev sibling parent kenji hara <k.hara.pg gmail.com> writes:
2012年4月20日0:56 Philippe Sigaud <philippe.sigaud gmail.com>:

 Jens:

 It's submitted.
 http://d.puremagic.com/issues/show_bug.cgi?id=7943






 (something like, one hour passes)

 Kenji:

 Posted compiler fix:
 https://github.com/D-Programming-Language/dmd/pull/890



 Man, you're wonderful Kenji. You never cease to amaze me. Your ability
 to correct bugs is borderline incredible.



Thanks.

Kenji Hara
Apr 19 2012