www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9078] New: non-static opCall is chosen instead of a default constructor

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9078

           Summary: non-static opCall is chosen instead of a default
                    constructor
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: void.unsigned gmail.com


--- Comment #0 from void.unsigned gmail.com 2012-11-25 10:26:49 PST ---
[From the thread at:
http://forum.dlang.org/thread/sntkmtabuhuctcbnlsgq forum.dlang.org]

The following code:

struct A
{
    int i;

    void opCall(int i) {
    }
}

void main() {
    auto a = A(42);
}

fails to compile with errors:
Error: variable deneme.main.a type void is inferred from initializer 
opCall(42), and variables cannot be of type void
Error: expression opCall(42) is void and has no value

A non-static opCall is chosen instead of a default constructor.
The non-static opCall() overloads should not interfere with construction.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 25 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9078


Maxim Fomin <maxim maxim-fomin.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxim maxim-fomin.ru


--- Comment #1 from Maxim Fomin <maxim maxim-fomin.ru> 2012-11-25 11:12:34 PST
---
Probably related:
- Issue 6579 Calling static method should *require* using type and not
instance, unless specified by author
- Issue 6036 Constructor, static opCall and object opCall

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 25 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9078



--- Comment #2 from Kenji Hara <k.hara.pg gmail.com> 2013-04-03 23:30:10 PDT ---
(In reply to comment #0)
[snip]

 A non-static opCall is chosen instead of a default constructor.
 The non-static opCall() overloads should not interfere with construction.


Currently function overload resolution does not consider whether the function
is static or not (just one exception of the rule is constructor call).
For example, function overloading based on static attribute does not work.

struct S
{
    void foo() {}
    static void foo() {}
}
void main()
{
    S s;
    s.foo();    // error
    S.foo();    // error
}

So, A(42) always invokes opCall, and fails to compile.

------

There is two workarounds.
1. define proper constructor

struct A
{
    int i;
    this(int i) { this.i = i; }
    void opCall(int i) {}
}
void main()
{
    auto a = A(42);   // OK
}

2. Use struct initializer for construction

struct A
{
    int i;
    void opCall(int i) {}
}
void main()
{
    A a = {42};   // OK
    a(42);   // invoke opCall
}

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