Thanks to C++ for inspiration, I even have proposal for such
syntax!
obj.free myFunc( args )
obj.member myFunc( args )
How about:
obj.myFunc( args ); // calls member function, even if free function exists
myFunc( obj, args ); // calls free function, even if member function
Jonathan M Davis:
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
On Tuesday, July 03, 2012 21:55:47 bearophile wrote:
So maybe it's worth accepting this limitation, to reduce
confusion for the people the read the code.
I would give a resounding no on that one. The confusion on how to actually
manage to be able to use your member function would t hen be even
On 07/03/2012 09:55 PM, bearophile wrote:
Jonathan M Davis:
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
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
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
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:
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!
http://www.reddit.com/r/programming/comments/vvpfy/uniform_function_call_syntax_in_d_gamedevnet/
Andrei
On Sun, 01 Jul 2012 11:13:10 -0400
Andrei Alexandrescu seewebsiteforem...@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
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
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
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
13 matches
Mail list logo
