Jump to page: 1 221  
Page
Thread overview
Discussion Thread: DIP 1044--Enum Type Inference--Community Review Round 1
Nov 18
monkyyy
Nov 18
IGotD-
Nov 19
Dukc
Nov 20
IchorDev
Nov 20
IchorDev
Nov 18
ryuukk_
Nov 18
bachmeier
Nov 18
monkyyy
Nov 22
XavierAP
Nov 23
deadalnix
Nov 23
ryuukk_
Nov 23
deadalnix
Nov 23
ryuukk_
Nov 23
ryuukk_
Nov 23
RTM
Nov 23
ryuukk_
Nov 27
XavierAP
Nov 27
ryuukk_
Nov 27
ryuukk_
Nov 28
XavierAP
Nov 28
XavierAP
Nov 23
XavierAP
Nov 24
XavierAP
Nov 24
bauss
Nov 18
bachmeier
Nov 24
IchorDev
Nov 22
IchorDev
Nov 20
IchorDev
Nov 22
IchorDev
Nov 19
Dukc
Nov 19
Ki Rill
Nov 20
IchorDev
Nov 19
ryuukk_
Nov 20
IchorDev
Nov 19
ryuukk_
Nov 19
Dukc
Nov 19
Dukc
Nov 19
bachmeier
Nov 19
ryuukk_
Nov 20
IchorDev
Nov 20
IchorDev
Alternative Possibility - Implicit with
Nov 20
bachmeier
Nov 20
zjh
Nov 20
zjh
Nov 20
zjh
Nov 20
zjh
Nov 20
zjh
Nov 20
zjh
Nov 20
zjh
Nov 20
IchorDev
Nov 21
TheGag96
Nov 21
TheGag96
Nov 19
monkyyy
Nov 19
cc
Nov 20
deadalnix
Nov 20
ryuukk_
Nov 20
ryuukk_
Nov 20
Dukc
Nov 20
deadalnix
Nov 20
IchorDev
Nov 20
Johan
Nov 20
ryuukk_
Nov 20
Johan
Nov 20
ryuukk_
Nov 20
IchorDev
Nov 20
IchorDev
Nov 20
CM
Nov 21
bauss
Nov 21
bauss
Nov 21
Basile.B
Nov 21
monkyyy
Nov 21
IchorDev
Nov 21
monkyyy
Nov 22
IchorDev
Nov 26
XavierAP
Nov 27
cc
Nov 27
XavierAP
Nov 27
bachmeier
Nov 27
ryuukk_
Nov 27
cc
Nov 22
IchorDev
Nov 22
IchorDev
Nov 22
IchorDev
Nov 22
bauss
Nov 22
zjh
Nov 22
zjh
Nov 22
IGotD-
Nov 22
claptrap
Nov 22
claptrap
Nov 22
bauss
Nov 24
cc
Nov 25
Dukc
Nov 25
IGotD-
Nov 24
IchorDev
Nov 25
bauss
Nov 22
TheGag96
Nov 23
IchorDev
Nov 22
XavierAP
Nov 23
IchorDev
Nov 23
XavierAP
Nov 23
bachmeier
Nov 24
IchorDev
Nov 23
IchorDev
Nov 23
XavierAP
Nov 23
deadalnix
Nov 23
RTM
Nov 23
Ishax
Nov 23
XavierAP
November 18

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

The review period will end at 11:59 PM ET on December 3, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the Feedback Thread. The Feedback Thread will be the source for the review summary that I will write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

And my blog post on the difference between the Discussion and Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

November 18

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

>

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the Feedback Thread. The Feedback Thread will be the source for the review summary that I will write at the end of this review round. I will post a link to that thread immediately following this post.

The Feedback Thread is here:

https://forum.dlang.org/post/yhlkkahzhabrhtyyqtpd@forum.dlang.org

November 18
>

using $
If I define opDollar to return an enum; and you define an opIndex to take enums; does it all work?

November 18

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":

[...]

I'm skeptical that adding this type of complexity to the language is worth it. Not just that this would add considerably to the learning curve, but because seemingly harmless changes to another part of your program would suddenly introduce ambiguity and cause it to no longer compile.

Consider this example:

import std;

enum JavaStyleGinormousName { a, b, c, d}

void main() {
    auto var = JavaStyleGinormousName.a;
    writeln(var);
    alias B = JavaStyleGinormousName;
    auto var2 = B.a;
    writeln(var2);
}

This makes everything explicit, with no surprises and no additional learning curve for the new user. This proposal essentially boils down to an implicit

alias $. = [something inferred by the compiler depending on the context
November 18

On Friday, 18 November 2022 at 18:32:44 UTC, bachmeier wrote:

>

no additional learning curve for the new user. This proposal essentially boils down to an implicit

alias $. = [something inferred by the compiler depending on the context

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

November 18

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

> >

using $
If I define opDollar to return an enum; and you define an opIndex to take enums; does it all work?

The $myEnum syntax is really hideous compared to the .myEnum. The .myEnum syntax feels natural where $myEnum looks like it is some kind macro parameter or something. There is a reason that all other example languages like Swift use the . syntax.

Is it possible to use the . syntax but there is a search hierarchy? If there is a global with the same enum name, you must give the full enum name. There might creep in serious bugs, however often you will have some kind of type mismatch.

The $ syntax is so ugly that I don't want this DIP in its current form.

November 18
On Fri, Nov 18, 2022 at 07:14:14PM +0000, IGotD- via Digitalmars-d wrote:
> On Friday, 18 November 2022 at 17:54:42 UTC, monkyyy wrote:
> > > using $
> > If I define opDollar to return an enum; and you define an opIndex to
> > take enums; does it all work?
>
> The $myEnum syntax is really hideous compared to the .myEnum. The
> .myEnum syntax feels natural where $myEnum looks like it is some kind
> macro parameter or something. There is a reason that all other example
> languages like Swift use the . syntax.

Yeah, `$` is really hideous and sticks out like a sore thumb in typical
D code.  On top of that, it overloads the current usage of $ to
something completely unrelated, which makes it look really messy.  Why
can't we just stick with `.`?


> Is it possible to use the . syntax but there is a search hierarchy? If
> there is a global with the same enum name, you must give the full enum
> name. There might creep in serious bugs, however often you will have
> some kind of type mismatch.
[...]

Here's my proposal: use `.` instead of `$`, and if .identifier is
ambiguous in any way at all, prohibit ITE and require spelling out the
enum in full. I.e., prohibit it if there's any ambiguity at all with a
module name, any global identifier, or it can be a member of multiple
enums currently in scope.

After all, your typical use case is an enum member with unique member
names, such that it's a pain to have to spell out the enum type since
it's already obvious from the name which enum it must belong to. If the
enum members don't have obviously unique names (i.e., it's ambiguous
with some top-level identifier), then it should be spelled out in full,
we should just prohibit eliding the type name.


T

--
Don't drink and derive. Alcohol and algebra don't mix.

November 18

Continuing discussion from the feedback thread:

On Friday, 18 November 2022 at 17:19:11 UTC, IchorDev wrote:

>

I presume this means that the list of cases must therefore be exhaustive?

More or less, yes.

That doesn't necessarily mean you have to list every possible context where ETI could be used one by one. A better approach might be to come up with a set of general, context-independent rules that specify how $identifier is evaluated, and then add special cases only as necessary to cover situations where the rules don't apply.

>

I might need help from some experienced implementers to work through that, since there are probably many aspects of D's syntax that I am unfamiliar with. For instance, mixing enum types with ints in an array literal causes it to be int[]. Should ETI work in that case? The easy answer is "no". However, what if D already has a mechanism for figuring out what types have already been used in an array literal? If so, then ETI could work in that example without a special-case, unambiguously.

I'm sure there are many people in the D community who would be happy to help you answer questions like these. Ultimately, though, it is your responsibility as the DIP author to make sure that those questions are addressed before the DIP is submitted to Walter and Atila for formal assessment.

If you feel you lack the experience to do this, you might consider recruiting someone more experienced as a co-author.

November 18
Lemme propose a generalization of the concept and an alternative syntax.

Consider the following code:

```
class ListBox {
   static struct Option {
         enum Type { Thing }
         Type type;
         string displayText;
   }

   void addOption(Option o) {}
}

ListBox b;

b.addOption(auto(auto.Thing, "foo"));
```


ok so what happens there is the pseudo-namespace auto refers to the type of the parameter. is is essentially magic `alias auto = typeof(arg);`

first layer i call the constructor, auto(...) is constructing a ListBox.Option, which it knows because that's what `addOption` takes, so that `auto` is just aliasing that name. The parens after it call the ctor exactly the same as if you wrote out `ListBox.Option`.

now that constructor takes a ListBox.Option.Type, so the auto used in *that* function call refers to *that*, just like your enum.

But it isn't limited to just enums.


This would also potentially work in return statements and assign expressions.

The type would have to be 100% unambiguous - the function must not be overloaded (well except maybe on arity) - so we avoid all that complication. Wouldn't work for templates.

Possible thing though:

listbox.addOption(to!auto("some string"))

might be allowed to work, using auto as the alias of the unambiguous parameter type could allow this too. I don't find this as important of a case to consider though.


BTW I used the word `auto` cuz it is a common thing but it could just as well be anything else, it is just a magic temporary alias after all.
November 18
The wordy:

    with(myObj) with(Size) with(Shape) with(State)

indeed doesn't look appetizing. But we could address this with:

    with (myObj, Size, Shape, State)

« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11