D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 12945 - Deprecation for legacy static opCall feature in initializing
Summary: Deprecation for legacy static opCall feature in initializing
Status: RESOLVED WONTFIX
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: All All
: P1 enhancement
Assignee: No Owner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-19 05:40 UTC by Kenji Hara
Modified: 2022-08-25 11:03 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Kenji Hara 2014-06-19 05:40:21 UTC
It is an old feature to emulate constructor call from D1 age.

struct S {
    int num;
    static S opCall(int n) {
        S s;
        s.num = n;
        return s;
    }
}
void main() {
    S s = 1;
    // This line is translated to:
    // S s = S.opCall(1);
}

But in D2, "implicit constructor call" feature properly supports such the initializing syntax.

struct S {
    int num;
    this(int n) {
        this.num = n;
    }
}
void main() {
    S s = 1;
    // This line is translated to:
    // S s = S(1);
}

Therefore, we can deprecate/remove the problematic opCall feature in initializing.
Comment 1 Jonathan M Davis 2014-06-19 05:55:32 UTC
static opCall without any parameters should continue work though, since you can't declare a default constructor.
Comment 2 Kenji Hara 2014-06-19 06:29:29 UTC
(In reply to Jonathan M Davis from comment #1)
> static opCall without any parameters should continue work though, since you
> can't declare a default constructor.

This proposal does not change it.
Comment 3 RazvanN 2022-08-25 11:03:35 UTC
I don't see why this shouldn't work in the absence of a constructor in S. Currently, constructor is preferred if both constructor and opCall are defined.

Closing this as WONTFIX.