Now that Phobos and DMD do not have any types that define an init member of any kind (TypeInfo.init was the only culprit), we should disallow defining members with the name init. This allows generic code to correctly assume that T.init will be the exact default initializer instance of a type.
I propose that in the next compiler release (at time of this writing, that would be 2.078) defining an init member should be a deprecation warning. Then at the next compiler release, it is an error.
Comment #1 by doob — 2017-10-31T07:41:38Z
I think it's a bit unfortunate that we're moving in this direction and are adding more of these kind of pseudo keywords. I would rather add __traits(init), deprecate the existing usage of "init" and eventually free up "init" to be used as an identifier. The nice thing about __traits is that it's its own kind of namespace and will not cause a conflict with user defined symbols.
Comment #2 by schveiguy — 2017-10-31T12:25:27Z
We are not adding anything. init already is a pseudo-keyword by convention, and is used everywhere. Moving to a __traits addition would be costly (so much code already uses T.init), and not offer really much benefit. Plus it would be disturbingly verbose. It would be a step backwards, IMO.
Comment #3 by doob — 2017-10-31T13:59:13Z
The benefit would be less reserved words. I think it was a design mistake from the beginning. Instead of fixing that we're now enforcing what was not really enforced before.
Comment #4 by schveiguy — 2017-10-31T14:14:34Z
That is exactly how I would describe "not much benefit". One less keyword that almost nobody is asking to have removed. I haven't seen much of a demand for using "init" anywhere except to mean what it currently means. This is not like "body," .init is used everywhere and pretty consistently. This is probably due to the fact that if you *do* define an init member, it breaks a lot of things, so you just don't do that. This proposal would formalize that into a more effective error and explanation.
Even though I disagree that .init was a design mistake (I would argue in fact that init should have been a full keyword), it is impossible to go back to the beginning without considering the consequences. Like it or not, we have to consider the effect on existing code when changing the meaning of an existing term.
Comment #5 by dlang-bot — 2021-05-11T06:01:27Z
@BorisCarvajal created dlang/dmd pull request #12512 "Issue 17954 - init member should be disallowed (deprecation)" mentioning this issue:
- Issue 17954 - init member should be disallowed (deprecation)
https://github.com/dlang/dmd/pull/12512
Comment #6 by razvan.nitu1305 — 2023-04-28T11:17:53Z
*** Issue 19233 has been marked as a duplicate of this issue. ***