[Issue 8616] Make pointers dereference with UFCS like they do with member functions

2022-12-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8616

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P2  |P4

--


[Issue 8616] Make pointers dereference with UFCS like they do with member functions

2018-01-22 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8616

Alex  changed:

   What|Removed |Added

 CC||sascha.or...@gmail.com

--


[Issue 8616] Make pointers dereference with UFCS like they do with member functions

2015-06-09 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8616

Andrei Alexandrescu  changed:

   What|Removed |Added

Version|unspecified |D2

--


[Issue 8616] Make pointers dereference with UFCS like they do with member functions

2012-09-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8616



--- Comment #7 from Kenji Hara  2012-09-04 19:58:12 PDT ---
Bug 8490 (already marked as "resolved invalid") is related.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8616] Make pointers dereference with UFCS like they do with member functions

2012-09-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8616


Jonathan M Davis  changed:

   What|Removed |Added

 CC||tommitiss...@hotmail.com


--- Comment #6 from Jonathan M Davis  2012-09-04 11:09:40 
PDT ---
*** Issue 8603 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8616] Make pointers dereference with UFCS like they do with member functions

2012-09-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8616


Jonathan M Davis  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |


--- Comment #5 from Jonathan M Davis  2012-09-04 11:08:44 
PDT ---
I'm making issue# 8603 a duplicate of this one instead, because IMHO, this one
is much better written (if nothing else, because it frames it as an enhancement
request rather than a bug like 8603 does).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8616] Make pointers dereference with UFCS like they do with member functions

2012-09-03 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8616



--- Comment #4 from Jonathan M Davis  2012-09-03 23:26:55 
PDT ---
> However, there is still a question what to do when both function are available

I'd definitely choose to go with making the code not compile. Otherwise, it
risks function hijacking. You could have

auto foo(S s) {...}

in my.pack which

S* s;
s.foo();

is happily calling, and then when you change the code to import your.pack with

auto foo(S* s) {...}

the code would silently change which function was being called. In general, we
try and make all such situations compilation errors in D.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8616] Make pointers dereference with UFCS like they do with member functions

2012-09-03 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8616



--- Comment #3 from Maxim Fomin  2012-09-03 23:20:34 PDT 
---
(In reply to comment #2)
> > The problem is that with this approach pointers are implicitly dereference
> Which is what happens when calling member functions on pointers to structs
> (unless no member variables are ever used within the function, so no
> dereferencing is necessary), so I don't see that as a problem.

Well, if pointers are dereferenced in case of accessing members, then the
problem already exists and can't be reason for not accepting enhancement
proposal.

However, there is still a question what to do when both function are available:
foo(T* ptr, ...);
foo(T val, ...);

I prefer to see the former to have priority over the latter. It may be useful
in cases when the first one was written intentionally for e.x. to check for
null pointer.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8616] Make pointers dereference with UFCS like they do with member functions

2012-09-03 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8616



--- Comment #2 from Jonathan M Davis  2012-09-03 20:35:09 
PDT ---
> The problem is that with this approach pointers are implicitly dereference

Which is what happens when calling member functions on pointers to structs
(unless no member variables are ever used within the function, so no
dereferencing is necessary), so I don't see that as a problem.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 8616] Make pointers dereference with UFCS like they do with member functions

2012-09-03 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8616


Maxim Fomin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ma...@maxim-fomin.ru
 Resolution||DUPLICATE


--- Comment #1 from Maxim Fomin  2012-09-03 20:27:18 PDT 
---
This is duplication of 8603.

The problem is that with this approach pointers are implicitly dereferenced.
Consider function:

void foo (T type) { }

which now can be called:

T var;
T *ptr;
type.foo();
ptr.foo();

*** This issue has been marked as a duplicate of issue 8603 ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---