Editions Ideas
libxmoc
libxmoc at gmail.com
Sat Dec 27 18:43:29 UTC 2025
On Saturday, 27 December 2025 at 15:33:23 UTC, Paul Backus wrote:
> On Saturday, 27 December 2025 at 14:00:19 UTC, libxmoc wrote:
>> None of that would matter if D had a specific way to use
>> builtins.
>>
>> Example:
>>
>> ```
>>
>> struct Actor
>> {
>> @:property // : = builtin
>> int hp();
>>
>> }
>> ```
>>
>> This way, language maintainers could use whatever names they
>> want without forcing users to cede common identifiers.
>
> D already has a solution for this: compiler-recognized UDAs in
> `core.attribute`.
>
> ```d
> // If 'property' weren't reserved, this could work
> import core.attribute: property;
>
> struct Actor
> {
> @property int hp();
> }
> ```
>
> The only thing keeping us from migrating existing attributes to
> `core.attribute` is backwards compatibility--existing code
> would be forced to add `import` statements to avoid breakage.
> But with editions, making a change like this is probably
> feasible.
It makes builtins look identical to user code, you can't tell
@property is special without checking imports, and that's bad.
Language features deserve syntax that signals their status.
It's the perfect opportunity for Editions to finally address this
long standing issue.
The renamed import solution proves it can be solved elegantly.
More information about the Digitalmars-d
mailing list