November 22
On Tuesday, 22 November 2022 at 12:27:41 UTC, claptrap wrote:
> Why not an error if it's ambiguous? There are ways to specify which you want if needed. And its probably unlikely enough that occasionally having to specify the enum name is not anything to be concerned about.

Error on ambiguity can break existing code. For example, this currently compiles, but would become ambiguous if we added enum type inference using .identifier syntax:

    enum E { x = 123 }
    int x = 456;
    static assert(.x == 456);

If we wanted to avoid breaking existing code, we would have to ensure that module-scope lookup *always* took precedence over enum member lookup.

Of course, the module scope .identifier syntax is not very widely used in the first place, so maybe a small risk of breakage is worth the benefit of nice syntax for enum members.
November 22

On Friday, 18 November 2022 at 18:54:01 UTC, monkyyy wrote:

>

Ds enum syntax is verbose compared to c; and the code block probaly isnt possible to write

I know I'm not teaching anything that's not known, but languages such as D, modern C++, C# etc requiring enums to be qualified, was absolutely intentional. And IMHO the reasons (against the C syntax) stand.

November 22

On Friday, 18 November 2022 at 15:37:31 UTC, Mike Parker wrote:

>

Discussion Thread

This is the discussion thread for the first round of Community Review of DIP 1044, "Enum Type Inference":

https://github.com/dlang/DIPs/blob/e2ca557ab9d3e60305a37da0d5b58299e0a9de0e/DIPs/DIP1044.md

At the very least I would require the "rationale" to say something more than "can be tedious" or at least provide a use case thereof (which cannot have a better solution within the existing language).

I concur about the $, looks terrible. And why is it better to type "$" than "Type."?

Is it because your enum names are too long (in some context)? Just alias them.

November 22
On 11/22/2022 10:25 AM, Adam D Ruppe wrote:
> On Tuesday, 22 November 2022 at 18:13:00 UTC, Walter Bright wrote:
>> It's the old tradeoff problem. You can make the bathroom bigger or the closet bigger, but not both.
> 
> my point is just your statement that nobody ever complained about implicit(this) is demonstrably false.

There's always somebody :-)
November 22
On 11/22/2022 10:26 AM, Adam D Ruppe wrote:
> On Tuesday, 22 November 2022 at 18:16:43 UTC, Walter Bright wrote:
>> compiles successfully and when run prints:
> 
> Did you implement the implicit with?
> 
> The point is that proposal will introduce a regression with that code.

I am not seeing where or how.
November 22
On 11/22/22 1:16 PM, Walter Bright wrote:
> On 11/21/2022 5:41 PM, Timon Gehr wrote:
>> On 22.11.22 01:49, Walter Bright wrote:
>>> On 11/20/2022 1:58 PM, Timon Gehr wrote:
>>>> On 20.11.22 22:32, Walter Bright wrote:
>>>>>
>>>>> But yes, it would be a (small) breaking change.
>>>>
>>>> I really wouldn't want to run into this:
>>>>
>>>> ```d
>>>> enum Role{
>>>>      guest,
>>>>      member,
>>>>      developer,
>>>> }
>>>>
>>>> void main(){
>>>>      Role r;
>>>>      writeln(r); // error
>> (Should perhaps be auto s = to!string(r);)
>>>> }
>>>> ```
>>>>
>>>> Too messy for me, but up to you.
>>>
>>> I'm not seeing where the shadowing is?
>>
>> That's indeed basically the point. It's invisible.
> 
> This code:
> 
> ---
> import std.stdio;
> 
> enum Role{
>       guest,
>       member,
>       developer,
> }
> 
> void main(){
>       Role r;
>       writeln(r); // error
> }
> ---
> 
> compiles successfully and when run prints:
> 
> guest
> 


To spell it out, when you write `case member:` what does `member` refer to? It currently, in the implementation of Phobos refers to the `member` iteration variable of the foreach inside to!string:

```d
foreach(member; EnumMembers!E) {
```

But if an implicit `with(Role)` is added to the case clause, now it only ever refers to `Role.member`. Essentially, you will end up with a switch that looks like:

```d
switch(e) {
   case Role.member: ...
   case Role.member: ...
   case Role.member: ...
   default: ...
}
```

Which will then be a compiler error.

The fix would be to rename the iteration variable to something the user couldn't possibly use. It's not pretty.

-Steve
November 23

On Tuesday, 22 November 2022 at 21:47:28 UTC, XavierAP wrote:

>

On Friday, 18 November 2022 at 15:37:31 UTC, Mike Parker wrote:

>

Discussion Thread

This is the discussion thread for the first round of Community Review of DIP 1044, "Enum Type Inference":

https://github.com/dlang/DIPs/blob/e2ca557ab9d3e60305a37da0d5b58299e0a9de0e/DIPs/DIP1044.md

At the very least I would require the "rationale" to say something more than "can be tedious" or at least provide a use case thereof (which cannot have a better solution within the existing language).

I concur about the $, looks terrible. And why is it better to type "$" than "Type."?

Is it because your enum names are too long (in some context)? Just alias them.

Aliasing requires figuring out a good alias name, polluting the namespace, and just feels like a hack. It's nice that D lets you, but I think a dedicated mechanism to reduce typing fatigue is better than obfuscation.

"What's this... M?" searches library "What? This isn't in here!" searches codebase "Oh, it's an alias of Magic. Who did this?"
vs
"$? Oh, this function call uses ETI. Let me see its declaration..." checks declaration "Okay it's Magic"

November 23

On Tuesday, 22 November 2022 at 15:42:27 UTC, TheGag96 wrote:

>

On the topic of the :ident syntax: It sounded good at first, but then I thought about our struct initialization syntax and our new named arguments syntax:

ColorPair pair = {
  fg : :red,
  bg : :green,
}

someFunc(fg : :red, bg: :green);

Seems kind of ugly. .identifier and #identifier are the best options IMO (but both unavailable lol). Implicit is decent I guess but looks kind of spooky.

Hmm. #identifier is so nice huh. I know #line might be niche, but I don't want to break it. It's got to be pretty useful for automated bindings. It is such a small part of the language that the thought crossed my mind, but I don't think the people using it would be pleased.

November 23

Nobody mentioned it here yet, so I figured I'd point out that the wonderful UplinkCoder has made a partial implementation of this DIP.
You can find the PR for it here: https://github.com/dlang/dmd/pull/14650

They have implemented a great deal of the proposed features in less than a day. They said ETI overloaded functions are incomplete and may take some time to finish, but I think that their progress so far demonstrates just how simple a feature ETI really is.

November 23

On Wednesday, 23 November 2022 at 04:43:16 UTC, IchorDev wrote:

> >

Is it because your enum names are too long (in some context)? Just alias them.

Aliasing requires figuring out a good alias name, polluting the namespace, and just feels like a hack. It's nice that D lets you, but I think a dedicated mechanism to reduce typing fatigue is better than obfuscation.

I agree aliasing should in general be avoided (certainly never down to single letters) in favor of good, readable names overall. It can help you when importing third party stuff whose names are bad overall or have room for improvement in your context.