View mode: basic / threaded / horizontal-split · Log in · Help
July 01, 2012
Uniform Function Call Syntax in D - GameDev.net
http://www.reddit.com/r/programming/comments/vvpfy/uniform_function_call_syntax_in_d_gamedevnet/

Andrei
July 01, 2012
Re: Uniform Function Call Syntax in D - GameDev.net
On Sun, 01 Jul 2012 11:13:10 -0400
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> http://www.reddit.com/r/programming/comments/vvpfy/uniform_function_call_syntax_in_d_gamedevnet/
> 
> Andrei

Good article.

One of the commenters brought up a point about confusion from possible
conflicts between UFCS funcs and member funcs. I was just about to
reply saying that's not an issue in D because it would be a conflict
error, but I did a little test first:

-----------------------
import std.stdio;

void bar(Foo f) {
   writeln("UFCS");
}

struct Foo {
   void bar() {
       writeln("Member");
   }
}

void main()
{
   Foo f;
   f.bar();
}
-----------------------

That successfully compiles and prints "Member". Same thing happens if
you move the UFCS func and Foo definition out into their own separate
modules. But I was expecting a conflict error at compile-time. Is this
a bug?
July 01, 2012
Re: Uniform Function Call Syntax in D - GameDev.net
On 7/1/2012 11:53 AM, Nick Sabalausky wrote:
> That successfully compiles and prints "Member". Same thing happens if
> you move the UFCS func and Foo definition out into their own separate
> modules. But I was expecting a conflict error at compile-time. Is this
> a bug?


No, it's correct behavior. A real member overrides.
July 02, 2012
Re: Uniform Function Call Syntax in D - GameDev.net
Am 01.07.2012 23:02, schrieb Walter Bright:
> On 7/1/2012 11:53 AM, Nick Sabalausky wrote:
>> That successfully compiles and prints "Member". Same thing happens if
>> you move the UFCS func and Foo definition out into their own separate
>> modules. But I was expecting a conflict error at compile-time. Is this
>> a bug?
>
>
> No, it's correct behavior. A real member overrides.

isn't that some sort of highjacking then?
July 02, 2012
Re: Uniform Function Call Syntax in D - GameDev.net
On Monday, July 02, 2012 07:00:23 dennis luehring wrote:
> Am 01.07.2012 23:02, schrieb Walter Bright:
> > On 7/1/2012 11:53 AM, Nick Sabalausky wrote:
> >> That successfully compiles and prints "Member". Same thing happens if
> >> you move the UFCS func and Foo definition out into their own separate
> >> modules. But I was expecting a conflict error at compile-time. Is this
> >> a bug?
> > 
> > No, it's correct behavior. A real member overrides.
> 
> isn't that some sort of highjacking then?

More like it avoids hijacking. It stops you from creating a function which is 
used instead of the one which is on the class or struct.

Granted, this does mean that you could be surprised about your external 
function not being called, and adding a new member function could cause your 
existing external function to no longer be called (which could be a problem), 
but realistically there's no other way to handle the situation. It's possible 
to explicitly give a path to the free function (e.g. path.to.function), but 
there's no way to do that for a member function, since there's only one way to 
call it. So, if you were forced to disambiguate, you could never indicate 
anything else other than the free function - not without introducing a new 
syntax to indicate the member function.

- Jonathan M Davis
July 02, 2012
Re: Uniform Function Call Syntax in D - GameDev.net
Am 02.07.2012 07:13, schrieb Jonathan M Davis:
> On Monday, July 02, 2012 07:00:23 dennis luehring wrote:
>> Am 01.07.2012 23:02, schrieb Walter Bright:
>> > On 7/1/2012 11:53 AM, Nick Sabalausky wrote:
>> >> That successfully compiles and prints "Member". Same thing happens if
>> >> you move the UFCS func and Foo definition out into their own separate
>> >> modules. But I was expecting a conflict error at compile-time. Is this
>> >> a bug?
>> >
>> > No, it's correct behavior. A real member overrides.
>>
>> isn't that some sort of highjacking then?
>
> More like it avoids hijacking. It stops you from creating a function which is
> used instead of the one which is on the class or struct.
>
> Granted, this does mean that you could be surprised about your external
> function not being called, and adding a new member function could cause your
> existing external function to no longer be called (which could be a problem),
> but realistically there's no other way to handle the situation. It's possible
> to explicitly give a path to the free function (e.g. path.to.function), but
> there's no way to do that for a member function, since there's only one way to
> call it. So, if you were forced to disambiguate, you could never indicate
> anything else other than the free function - not without introducing a new
> syntax to indicate the member function.
>
> - Jonathan M Davis
>

but the compiler selects the member-functions silently - thats odd, ok i 
will see it very fast - but then i need to change my code anyway - so 
whats the reason for the silent "overwrite"?
July 02, 2012
Re: Uniform Function Call Syntax in D - GameDev.net
On Monday, 2 July 2012 at 05:55:20 UTC, dennis luehring wrote:
> Am 02.07.2012 07:13, schrieb Jonathan M Davis:
>> On Monday, July 02, 2012 07:00:23 dennis luehring wrote:
>>> Am 01.07.2012 23:02, schrieb Walter Bright:
>>> > On 7/1/2012 11:53 AM, Nick Sabalausky wrote:
>>> >> That successfully compiles and prints "Member". Same thing 
>>> >> happens if
>>> >> you move the UFCS func and Foo definition out into their 
>>> >> own separate
>>> >> modules. But I was expecting a conflict error at 
>>> >> compile-time. Is this
>>> >> a bug?
>>> >
>>> > No, it's correct behavior. A real member overrides.
>>>
>>> isn't that some sort of highjacking then?
>>
>> More like it avoids hijacking. It stops you from creating a 
>> function which is
>> used instead of the one which is on the class or struct.
>>
>> Granted, this does mean that you could be surprised about your 
>> external
>> function not being called, and adding a new member function 
>> could cause your
>> existing external function to no longer be called (which could 
>> be a problem),
>> but realistically there's no other way to handle the 
>> situation. It's possible
>> to explicitly give a path to the free function (e.g. 
>> path.to.function), but
>> there's no way to do that for a member function, since there's 
>> only one way to
>> call it. So, if you were forced to disambiguate, you could 
>> never indicate
>> anything else other than the free function - not without 
>> introducing a new
>> syntax to indicate the member function.
>>
>> - Jonathan M Davis
>>
>
> but the compiler selects the member-functions silently - thats 
> odd, ok i will see it very fast - but then i need to change my 
> code anyway - so whats the reason for the silent "overwrite"?

If it didn't overwrite silently, it would mean every single free 
function is now not a valid member function name. Better hope 
your users don't import a module that uses said free function.

In my opinion, the current way is the one that makes sense. And 
extension methods in C# do this as well.
July 02, 2012
Re: Uniform Function Call Syntax in D - GameDev.net
On Monday, July 02, 2012 07:54:56 dennis luehring wrote:
> Am 02.07.2012 07:13, schrieb Jonathan M Davis:
> > On Monday, July 02, 2012 07:00:23 dennis luehring wrote:
> >> Am 01.07.2012 23:02, schrieb Walter Bright:
> >> > On 7/1/2012 11:53 AM, Nick Sabalausky wrote:
> >> >> That successfully compiles and prints "Member". Same thing happens if
> >> >> you move the UFCS func and Foo definition out into their own separate
> >> >> modules. But I was expecting a conflict error at compile-time. Is this
> >> >> a bug?
> >> > 
> >> > No, it's correct behavior. A real member overrides.
> >> 
> >> isn't that some sort of highjacking then?
> > 
> > More like it avoids hijacking. It stops you from creating a function which
> > is used instead of the one which is on the class or struct.
> > 
> > Granted, this does mean that you could be surprised about your external
> > function not being called, and adding a new member function could cause
> > your existing external function to no longer be called (which could be a
> > problem), but realistically there's no other way to handle the situation.
> > It's possible to explicitly give a path to the free function (e.g.
> > path.to.function), but there's no way to do that for a member function,
> > since there's only one way to call it. So, if you were forced to
> > disambiguate, you could never indicate anything else other than the free
> > function - not without introducing a new syntax to indicate the member
> > function.
> > 
> > - Jonathan M Davis
> 
> but the compiler selects the member-functions silently - thats odd, ok i
> will see it very fast - but then i need to change my code anyway - so
> whats the reason for the silent "overwrite"?

Yes, but as I said, if it _didn't_ select the member function when there was a 
conflict, it would be impossible to call the member function whenever there was 
a conflict. There is no way to indicate that you mean a member function rather 
than a free function. The normal way to do that is to use member function call 
syntax, and UFCS allows you to then use that for free functions. With conflicts 
between free functions, you can do path.to.func or other.place.func instead of 
just func, but with a member function, that's not possible. So, without adding 
new syntax to the language, it was essentially impossible to do anything other 
than pick the member function whenever there's a conflict.

- Jonathan M Davis
July 02, 2012
Re: Uniform Function Call Syntax in D - GameDev.net
On 07/01/2012 11:11 PM, Jonathan M Davis wrote:

> Yes, but as I said, if it _didn't_ select the member function when 
there was a
> conflict, it would be impossible to call the member function whenever 
there was
> a conflict.

I wouldn't be a fan of it but I think it would still be possible:

class C
{
    void foo()
    {}
}

void main()
{
    auto c = new C();
    auto c_foo = &c.foo;
    c_foo();
}

Ali
July 03, 2012
Re: Uniform Function Call Syntax in D - GameDev.net
On Monday, 2 July 2012 at 06:11:22 UTC, Jonathan M Davis wrote:
> So, without adding new syntax to the language, it was 
> essentially impossible to do anything other than pick the 
> member function whenever there's a conflict.

Thanks to C++ for inspiration, I even have proposal for such
syntax!

       obj.free myFunc( args )
       obj.member myFunc( args )

:D
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home