On 11/19/2022 5:01 AM, Adam D Ruppe wrote:
> Something I do before making a post is to run it through the compiler to ensure it actually works like I'm claiming it works. You should do this too.

True.

On 11/19/2022 4:22 AM, Timon Gehr wrote:
> On 11/19/22 05:22, Walter Bright wrote:
>> Since the DIP allows expressions containing such enum inferences, it looks like we are faced with the possibility of having to re-run the semantic pass for enum arguments for every enum overload.
> 
> Only if the new feature is actually used,

Yes, but that would require a significant redo of the semantic routines, which modify the ASTs in-place.

On 19.11.22 18:29, Vladimir Panteleev wrote:
> 
> I would like to suggest the following changes for consideration:
> 
> - Replace the `$ Identifier` syntax with `: Identifier`, to match other languages like Ruby and Lisp.
> 
> - The `: Identifier` syntax creates a value of a dynamic pseudo-type (a bit like `typeof(null)`).
> 
>    - The type's name is `typeof(:Identifier)`.
> 
>    - The type has size 0 and holds a single value.
> 
>    - The type is implicitly convertible to any enum type which has a member with the same name as `Identifier`.
> 
> I think this is a more precise and immediately implementable definition of the mechanics. Not sure if a good thing or not, but this will also allow using `:keyword`s stand-alone, like in Ruby/Lisp in a congruent manner. For the purposes at hand (enum type inference), it will also allow passing through the short-hand identifier to templated and `auto` functions.

I think this makes some sense. (I especially prefer the syntax and the standalone symbol approach). With this proposal, we'd have to think about the matching level for function overloads (delegates match precisely even if they require inference), as with your approach one can overload an enum argument against a typeof(:identifier). Probably exact match would be better than match with implicit conversion, but idk if it is worth changing/bending the overloading rules over this.

On 20.11.22 02:00, deadalnix wrote:
> 
> I have very simple feedback.
> 
> STOP CHANGING THE GOD DAMN SYNTAX!
> STOP, STOP, STOP, and if you still have some doubt, STOP!
> 
> Every time, it breaks a ton of tools.
> 
> It's not worth it.
> ...

It's not worth freezing the language over temporary tool breakage. Just don't update the compiler until the tools have caught up.

> If typing the name of the enum is too long, then just use `with` or `alias E = MyEnumNameThatIsTooLongAndAnoyingToType;`.
> ...

Right, if typing the name of the enum is too long, then just type the name of the enum. x)

> These changes do not solve any actual problem.

Well, they do.

> They just break tools.
> 
> STOP IT!

There has to be a better way.

On 19.11.22 05:14, Walter Bright wrote:
> 
> You're referring, of course, to the "contextual" part of the DIP, where the lookup works only in a subset of cases. The contextual lookup can result in some odd cases like:
> 
> ---- module A ----
>      private enum E { e; };
>      public void dra(E);
> ------------------
>      import A;
> 
>      dra($e);
> ------------------
> ...

This is a good point. However, it's an existing oddity in the language that public symbols can use private symbols in their signatures.

> Is that a good thing?

I think contextual lookup is better than trying to do a lookup within the scopes of all visible enumerations. Vladimir's suggestion where we would add symbol literals is even better.

I have somewhat mixed feelings about implicit `with`. On one hand, it's even more convenient than `$e` `_.e`, `:e` etc, but on the other hand it's even less predictable for a user where it will work, and it can shadow variables from outer scopes (which is also a breaking change).

> I'm not sure. This is also not addressed in the DIP.

I don't have particularly strong feelings about this feature either way, but it is quite popular and I have been annoyed by the need to write `with` statements in the past. (But maybe that's partly because the emacs d mode is not so great at indenting
switch(x) with(E){
    case a: ...
}.)

On 20.11.22 04:20, Walter Bright wrote:
> On 11/19/2022 4:22 AM, Timon Gehr wrote:
>> On 11/19/22 05:22, Walter Bright wrote:
>>> Since the DIP allows expressions containing such enum inferences, it looks like we are faced with the possibility of having to re-run the semantic pass for enum arguments for every enum overload.
>>
>> Only if the new feature is actually used,
> 
> Yes, but that would require a significant redo of the semantic routines, which modify the ASTs in-place.
> 

To some extent I think this is the case, but function literals already defer the semantic pass in some way, so it seems feasible.

On Sunday, 20 November 2022 at 09:39:11 UTC, Timon Gehr wrote:
> It's not worth freezing the language over temporary tool breakage. Just don't update the compiler until the tools have caught up.
>

Here is where you are wrong: it's not temporary breakage, it's permanent, but this whole circus happens every few of months.

We can argue all day long, but the proof is in the pudding: D tooling is abysmal and kinda broken pretty much everywhere. It's not hard to figure out why: people implement D support at some point, and then changes accumulate and support kinda work, kinda not.

> There has to be a better way.

There is. Bundle the breakage, and release them all at once every couple of years. Every single language out there does that, there is a reason for it.