Bug 19619 – Temporary solution for attribute extensibility problem

Status
NEW
Severity
enhancement
Priority
P4
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2019-01-26T16:27:17Z
Last change time
2024-12-13T19:02:13Z
Keywords
spec
Assigned to
No Owner
Creator
anonymous4
Moved to GitHub: dmd#19534 →

Comments

Comment #0 by dfj1esp02 — 2019-01-26T16:27:17Z
Given difficulties with adding compiler recognized attributes as seen in DIP1017, how about temporarily reserving UDAs with certain naming convention as keywords (like @safe)? Because they have usual UDA syntax, their status as keywords can be lifted later (ldc and gdc already implement compiler recognized UDAs). Possible naming conventions: 1. Prefix 'd', e.g. @dnoreturn 2. Prefix '_', e.g. @_noreturn or @_noreturn_ 3. Prefix 'core', e.g. @core_noreturn Declared like --- module core.attribute; struct noreturn { bool enabled; } alias noreturn _noreturn_; --- Compiler should create normal UDAs for them to verify that specified symbols are visible (declared in core.attribute). Can this simplify language extensibility?
Comment #1 by dhasenan — 2019-01-26T16:51:58Z
https://dlang.org/spec/lex.html#identifiers says: "Implementation Defined: Identifiers starting with __ (two underscores) are reserved." Adding the attributes to core.attribute would pretty much obviate this. You can use selective, renamed, and static imports to handle name conflicts. This is much more true with the proposed @future symbol reservation feature, which would allow a deprecation cycle to introduce a new symbol.
Comment #2 by dfj1esp02 — 2019-01-27T10:20:37Z
AIU the problem with normal core.attributes is that dmd backend glue code has difficulty recognizing UDAs (as if they are only for introspection).
Comment #3 by robert.schadek — 2024-12-13T19:02:13Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/19534 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB