Bug 13184 – better error messages for incorrect constructors

Status
NEW
Severity
enhancement
Priority
P4
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2014-07-22T12:06:01Z
Last change time
2024-12-13T18:22:38Z
Assigned to
No Owner
Creator
Manu
Moved to GitHub: dmd#17670 →

Comments

Comment #0 by turkeyman — 2014-07-22T12:06:01Z
I just spent ages stuffing around trying to find 'shared static this()'. My first instinct was '__gshared this()', then '__gshared static this()'. Both produce unhelpful error messages. It'd be nice if it suggested what I actually wanted :) There may be other permutations that don't make sense too, which should probably get helpful error messages aswell.
Comment #1 by razvan.nitu1305 — 2018-04-18T12:42:17Z
It seems that __gshared is ignored when applied to a constructor, which seems to be in trend with how D usually treats identifiers which are used where they not supposed to. The same happens with extern(C) : struct S { extern (C) void foo() {} } This code will compiler even though it doesn't make any sense to mark a struct function as extern(C). I would say we should close this as wontfix.
Comment #2 by slavo5150 — 2018-04-18T13:12:29Z
(In reply to RazvanN from comment #1) > It seems that __gshared is ignored when applied to a constructor, which > seems to be in trend with how D usually treats identifiers which are used > where they not supposed to. The same happens with extern(C) : Yes, that does seem to be the trend, and I don't like it. `static` methods at the module level is another; the `static` is pointless, but the compiler doesn't seem to mind. I would prefer that, if a token is meaningless, the compiler emit an error.
Comment #3 by razvan.nitu1305 — 2018-04-18T13:47:32Z
(In reply to Mike Franklin from comment #2) > (In reply to RazvanN from comment #1) > > It seems that __gshared is ignored when applied to a constructor, which > > seems to be in trend with how D usually treats identifiers which are used > > where they not supposed to. The same happens with extern(C) : > > Yes, that does seem to be the trend, and I don't like it. `static` methods > at the module level is another; the `static` is pointless, but the compiler > doesn't seem to mind. > > I would prefer that, if a token is meaningless, the compiler emit an error. I think that an error is too much, but a warning could be appreciated. On the other hand, I know that Walter is against warnings so I don't know if this is going to advance in any way.
Comment #4 by turkeyman — 2018-04-19T01:02:15Z
I think it should definitely emit an error. There may come some time in the future where it is decided that application of the attribute may like to mean something new and useful, but if we leave this situation as is, then that is a breaking change. If we expect that meaningless attributes produce compile errors, then in the future when we want to make it meaningful, we can do it without breaking any code.
Comment #5 by robert.schadek — 2024-12-13T18:22:38Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17670 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB