Bug 14854 – @disable this inconsistent between structs and classes
Status
RESOLVED
Resolution
WONTFIX
Severity
minor
Priority
P3
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2015-08-01T04:55:59Z
Last change time
2023-03-31T10:57:51Z
Keywords
pull, trivial
Assigned to
No Owner
Creator
Jonathan M Davis
Comments
Comment #0 by issues.dlang — 2015-08-01T04:55:59Z
This code
class C1
{
@disable this() {}
}
class C2
{
@disable this();
}
struct S1
{
@disable this() {}
}
struct S2
{
@disable this();
}
void main()
{
}
results in this compilation error:
q.d(13): Error: constructor q.S1.this default constructor for structs only allowed with @disable and no body
For structs, it's clearly required that @disable this() not have a body, whereas for classes, for some reason, the compiler doesn't care. The error message does explicitly use the word struct, which implies that this difference is intentional, but I don't see any reason to allow for the inconsistency. It just makes it less obvious, which syntax you should be using.
And in general, I don't see any reason to allow bodies on @disabled functions. One interesting side effect of putting a body on the @disabled default constructor on a class is that it actually affects the code coverage analyzer, because the lines inside the body never run and count as uncovered.
So, I suggest that we deprecate having bodies on _all_ @disabled functions and move to making it an error like it is with @disabling the init property on a struct.
Comment #1 by tiberiulepadatu14 — 2018-07-08T18:46:26Z
Hello!
So the solution that you suggest is to make the compiler give an error when the @disabled is used?
If so, do you think that this will impact some code somewhere else?
I think that I will be able to write a fix for this.
Comment #2 by issues.dlang — 2018-07-09T05:32:28Z
My suggestion is to make it an error when @disable is used on a function with a body - just like happens right now when you do it with @disable this() {} on a struct. I can't think of any reason why this would be a problem. Certainly, I don't see why it would ever make sense to declare an @disabled function with a body. By definition, it's unreachable.
However, it will need to be done as a deprecation first in case anyone does have code that has @disable on a function with a body (like in the example here with a class).
Comment #3 by dlang-bot — 2019-03-04T18:52:41Z
@tibi77 created dlang/dmd pull request #9413 "Fix Issue 14854 - @disable this inconsistent between structs and classes" fixing this issue:
- Fix Issue 14854 - @disable this inconsistent between structs and classes
https://github.com/dlang/dmd/pull/9413
Comment #4 by dlang-bot — 2019-03-05T16:16:48Z
@tibi77 created dlang/phobos pull request #6893 "Remove redundant body of @disable functions. Issue 14854 DMD" mentioning this issue:
- Remove redundant body of @disable functions. Issue 14854 DMD
https://github.com/dlang/phobos/pull/6893
Comment #5 by dlang-bot — 2019-03-06T01:00:09Z
dlang/phobos pull request #6893 "Remove redundant body of @disable functions. Issue 14854 DMD" was merged into master:
- 336047098929c141f2fdd7b00c25d0aec3abedda by Lepadatu Tiberiu:
Remove redundant body of @disable functions. Issue 14854 DMD
https://github.com/dlang/phobos/pull/6893
Comment #6 by dlang-bot — 2023-03-30T16:27:37Z
@Mai-Lapyst created dlang/dmd pull request #15052 "Fix issue 14854 - @disable this inconsistent between structs and classes" fixing this issue:
- Fix issue 14854 - @disable this inconsistent between structs and classes
https://github.com/dlang/dmd/pull/15052
Comment #7 by razvan.nitu1305 — 2023-03-31T10:57:51Z