November 24, 2022

On Wednesday, 23 November 2022 at 10:18:21 UTC, Quirin Schroll wrote:

>

I know it sounds nitpicky, but I really dislike like acronym. “ETI” is used (at least) in C++ for “explicit template instantiation.” D has templates, so ETI can be a source for confusion. The term has been used in the forum unrelated to C++.

I don’t care for the wording of the DIP, but for what people will refer to it in the forum. If it makes it into the spec, it would be great if you could find something else. E.g. “type-inferred enums” (TIE) is not that different, IMO “type inferred enum members” (TIEM) is even better. Another one would be “implicit enum member” (IEM).

D is not C++. The DIP proposes enum type inference, which is a descriptive term.
When the feature goes into the spec, I think it should be referred to as simply “type inference”, as it might not be specific to enums forever. I don't really know how to communicate that in the DIP, though. I feel that none of the terms you proposed really describe the feature accurately or succinctly in the same way as "enum type inference".

November 24, 2022

On Wednesday, 23 November 2022 at 16:11:32 UTC, Daniel N wrote:

>
  1. using new symbols $(or any other unused symbol) for a minor feature is wasteful, compared to adding new meta/codegen features etc.

It is a minor feature at the moment. There's nothing stopping it from becoming more generalised later. # is also used exclusively for #line, which prohibits its use almost anywhere else (except strings), but I am not against that either. $ can still be used as a binary operator in the future, or in regular strings for interpolation or what-have-you.

>
  1. Implicit 'with' for switch statements as proposed by Walter is more elegant and doesn't require any new symbols/syntax and is also more efficient from a compiler performance perspective as $ could refer to any enum, whereas the implicit 'with' only adds one enum.

If it only works in case statements then it does not functionally replace the usefulness of ETI:

enum MyEnum{ a,b,c,d }
struct Obj{ MyEnum one, two; }

void myFn(MyEnum param){}
void myDefaultFn(MyEnum param=$d){}
void myTempFn(alias x: MyEnum)(){}

void main(){
    Obj  myS1 = {one: $a, two: $b};
    auto myS2 = Obj($a, $b);

    myFn($a);
    myFn($b + $b);

    myDefaultFn();
    myDefaultFn($c);

    myTempFn($a);
}

You might argue that an explicit with(T) would be nice in the above example. Well, it's an example. In my experience, enum usage tends to be very spread out across codebases. Therefore using with(T) would lead to me doing more typing because I would need 1 with per enum use.

November 24, 2022

On Wednesday, 23 November 2022 at 16:11:32 UTC, Daniel N wrote:

>

[implicit 'with'] is more efficient from a compiler performance perspective as $ could refer to any enum, whereas the implicit 'with' only adds one enum.

I thought I should also add that this is completely false. In a case statement, $member can only refer to a member of the type enum type used in the switch. If it does not, the compiler will return an error.

November 27, 2022

On Friday, 18 November 2022 at 15:38:59 UTC, Mike Parker wrote:

>

You can find DIP 1044 here:

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

The "rationale" is virtually empty, it contains only a personal statement that qualifying enums "can be tedious". Could this (essential) first part of the DIP be extended, explaining what the problem is that it aims to solve, providing some use cases -- and why is the proposed change a better solution than any possible with the current language, and the best possible solution in general?

November 30, 2022

On Sunday, 27 November 2022 at 09:00:50 UTC, XavierAP wrote:

>

The "rationale" is virtually empty, it contains only a personal statement that qualifying enums "can be tedious". Could this (essential) first part of the DIP be extended, explaining what the problem is that it aims to solve, providing some use cases -- and why is the proposed change a better solution than any possible with the current language, and the best possible solution in general?

Good point, it is relatively short. It's hard to write a long and detailed rationale for a feature as small as a simple shortcut to alleviate unnecessarily repeating yourself in your code. That said, I will try and expand the rationale section but it might not be pretty. I'm a programmer not an author, after all.

1 2 3
Next ›   Last »