Editions Ideas

[Timon Gehr]

On 12/16/25 21:45, Richard (Rikki) Andrew Cattermole wrote:
> 
> On 17/12/2025 9:35 AM, Nick Treleaven wrote:
>> On Monday, 15 December 2025 at 16:59:07 UTC, Lance Bachmeier wrote:
>>> On Monday, 15 December 2025 at 12:26:04 UTC, Nick Treleaven wrote:
>>>> For structs, I think there was some plan to replace it, but I never 
>>>> saw details.
>>>
>>> Walter has indicated a desire to not use editions as an excuse to 
>>> ruin the language.
>>>
>>> alias this with structs is very useful. There is no reason to remove 
>>> it or make it unusable just because a few people think it can be 
>>> dangerous. One might also argue that pointers are dangerous, but 
>>> that's not an argument for removing them. Removal of alias this would 
>>> make the language unusable for me.
>>
>> I don't know if there is a plan now to replace it, I'd guess not. I am 
>> not aware of any reason why `alias this` should be removed (for 
>> structs at least). If there was a replacement feature, it should be 
>> capable of everything `alias this` can currently do IMO, so that there 
>> would be an upgrade path.
>>
>> There was a project item to 'Explore a replacement for alias this':
>> https://github.com/orgs/dlang/projects/22/views/1? 
>> pane=issue&itemId=29572699
>>
>> Though that was part of a set which was closed (maybe last year).
> 
> I have my own plans, but they'll need to be discussed next month.
> 
> https://forum.dlang.org/post/llqcjziyurwmyhzseonm@forum.dlang.org
> 
> We don't need alias this semantic, but we do need a fallback lookup via 
> a method.
> 
> Get rid of the overriding capability, and let things stay single 
> inheritance.

D also allows multiple module imports, just use the same lookup rules 
and disambiguation strategies.

It's a solved problem. The reason why we were not able to do this is 
that it breaks code that relies on the ad-hoc mess that has grown over 
the years instead. There is no need to go overboard and delete the whole 
concept now that we got editions that allow us to solve the problem in 
the obvious way.

Of course, we can also use different syntax. Forwarding to members is 
useful without implicit conversion and even vice-versa.