Bug 1840 – Fix ambiguity errors over struct static opCall and regular opCall

Status
RESOLVED
Resolution
WORKSFORME
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86
OS
Windows
Creation time
2008-02-14T22:06:00Z
Last change time
2015-06-09T05:11:35Z
Assigned to
nobody
Creator
wbaxter
Depends on
6036
Blocks
7210

Comments

Comment #0 by wbaxter — 2008-02-14T22:06:48Z
Since the de-facto way to construct structs is with static opCall, it basically makes it impossible to make interesting functors using structs. Also gets in the way of various things that one might like to do in numerical code overloading opCall to do alternative indexing styles (for instance to mean raw indexing vs strided indexing, or to mean element indexing rather than row-wise indexing etc). Unfortunately you quickly run into cases where your static opCalls (fake constructors) conflict with your non-static ones. You can work around by using something like a create() method instead of static opCalls. But then users of your code will be confused since they've been trained to look for static opCall to be the "constructor". Or you can just not overload opCall and use some regular function like "get()". But that's not really a good solution for functors, since the whole point there is that they should be callable like functions. This needs to be fixed somehow. The compiler should be able to distinguish betweem StructName(...) and structInstance(...) usages. The most obvious solution is clearly just to allow using this() syntax for structs.
Comment #1 by strtr — 2010-11-03T18:16:17Z
I would like to up this to a bug. S s; S(); // static void opCall() s(); // void opCall() Seen like this the calls have different names, thus should not conflict.
Comment #2 by bearophile_hugs — 2011-04-28T14:50:10Z
Bug 4053 seems similar or the same. Both have 1 (different) vote. This is an important issue I hit all the time in my code.
Comment #3 by bearophile_hugs — 2012-10-06T11:03:11Z
Seems fixed. See Issue 6036