Menu
Search

Forums

Forum Index

November 21, 2022
Gravatar of Patrick SchluterPosted by Patrick Schluter
in reply to Johan		Reply
Patrick Schluter
Gravatar of Patrick Schluter
Posted in reply to Johan


Reply

On Sunday, 20 November 2022 at 16:14:41 UTC, Johan wrote:

> >

These changes do not solve any actual problem. They just break tools.

I quite strongly agree.

Me too.

>

The DIP does not show any real improvements. The rationale mentions "few drawbacks" but then does not mention those actual drawbacks, so people can judge whether they are few or not.

The DIP show this example as an improvement:

    myObj.myFn($medium, $square, $undefined);

Is the height medium?, the location the town square?, the shape undefined?
This is the "worse" version:

    myObj.myFn(Size.medium, Shape.square, State.undefined);

Code will be read much more often than it is written.
Please give a real world example where really the enum name is so long and tedious that reading it is worse than without (and where with does not solve the problem).

Indeed. This DIP goes also in direct contradiction to the named parameter DIP, which strives to make the code more explicit, with naming the parameter. This thing would then require for readability to call like that:

    myObj.myFn(Size: $medium, Shape: $square, State: $undefined);
>

Besides tooling, also take into account someone relatively unfamiliar with D, stumbling upon a $. (now what the heck is this gratuitous obfuscation?)

Making D as "readable" as Perl. :-)

November 21, 2022
Gravatar of Basile.BPosted by Basile.B
in reply to Mike Parker		Reply
Basile.B
Gravatar of Basile.B
Posted in reply to Mike Parker


Reply

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

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.

The EnumExpression shortucts the whole shadowing problem

EnumExpression ::= "enum" "." Identifier

So when that kind of expression is resolved, you just have to look at if there's an enum put in the current scope for that special inference case and if it contains the right member.

That would look like this

EnumType myBitset = enum.flag1 | enum.flag3

So you push EnumType in the scope used to solve the assign expression.
you see ?

November 21, 2022
Gravatar of monkyyyPosted by monkyyy
in reply to Mike Parker		Reply
monkyyy
Gravatar of monkyyy
Posted in reply to Mike Parker


Reply

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

>

D

The issue is that c bindings tend to be verbose; so what if importc(with a flag?) flattened enums into global scope, mimicking c

given enum foo{a,b} in a .c; is traslated to enum a=0; enum b=1 In the internal ast; sofoo bar=a works in a .d

November 21, 2022
Gravatar of TheGag96Posted by TheGag96
in reply to IchorDev		Reply
TheGag96
Gravatar of TheGag96
Posted in reply to IchorDev


Reply

On Sunday, 20 November 2022 at 16:29:46 UTC, IchorDev wrote:

>

I'm up for changing it to something else, like I've said. It's just that I can't think of anything better except maybe #member, but I think # is reserved right?

Could you elaborate on this? I thought I was going nuts until I saw this reply because last time this was brought up, # seemed to be the most agreed-upon alternative to .. If we were to never deprecate the global scope operator, # honestly kind of makes a lot of sense... It calls back to the "num(ber)" part of "enumeration". What is # reserved for exactly?

November 21, 2022
Gravatar of Paul BackusPosted by Paul Backus
in reply to TheGag96		Reply
Paul Backus
Gravatar of Paul Backus
Posted in reply to TheGag96


Reply

On Monday, 21 November 2022 at 15:45:59 UTC, TheGag96 wrote:

>

On Sunday, 20 November 2022 at 16:29:46 UTC, IchorDev wrote:

>

I'm up for changing it to something else, like I've said. It's just that I can't think of anything better except maybe #member, but I think # is reserved right?

Could you elaborate on this? I thought I was going nuts until I saw this reply because last time this was brought up, # seemed to be the most agreed-upon alternative to .. If we were to never deprecate the global scope operator, # honestly kind of makes a lot of sense... It calls back to the "num(ber)" part of "enumeration". What is # reserved for exactly?

# is used to indicate the start of a special token sequence.

November 21, 2022
Gravatar of IchorDevPosted by IchorDev
in reply to Mike Parker		Reply
IchorDev
Gravatar of IchorDev
Posted in reply to Mike Parker


Reply

If you'd like to vote about what ETI syntax you'd prefer, I've opened a poll to keep track of how many people like which syntax.
The options I've listed are limited to ones that don't break compatibility with existing code. If you'd like an option added, let me know.
https://strawpoll.com/polls/PKglzqaGJyp

November 21, 2022
Gravatar of TheGag96Posted by TheGag96
in reply to Paul Backus		Reply
TheGag96
Gravatar of TheGag96
Posted in reply to Paul Backus


Reply

On Monday, 21 November 2022 at 15:48:55 UTC, Paul Backus wrote:

>

# is used to indicate the start of a special token sequence.

Wow. Only barely recalled ever seeing this feature from the depths of my memory. Thanks, lol. That's a shame...

I like this proposed feature, but I don't know if I like the $ syntax. At first blush it's a bit ugly looking and might clash visually somewhat with the $ operator. The enum. suggestion isn't super bad but it's a bit wordy. Regardless I think it would be super nice to have parity with other languages with regard to less wordy enum usage.

November 21, 2022
Gravatar of monkyyyPosted by monkyyy
in reply to IchorDev		Reply
monkyyy
Gravatar of monkyyy
Posted in reply to IchorDev


Reply

On Monday, 21 November 2022 at 16:23:51 UTC, IchorDev wrote:

>

If you'd like to vote about what ETI syntax you'd prefer, I've opened a poll to keep track of how many people like which syntax.
The options I've listed are limited to ones that don't break compatibility with existing code. If you'd like an option added, let me know.
https://strawpoll.com/polls/PKglzqaGJyp

 
enum bar{foo,foobar}
bar b=🃏.foo;
November 21, 2022
Gravatar of Guillaume PiolatPosted by Guillaume Piolat
in reply to IchorDev		Reply
Guillaume Piolat
Gravatar of Guillaume Piolat
Posted in reply to IchorDev


Reply

On Monday, 21 November 2022 at 16:23:51 UTC, IchorDev wrote:

>

If you'd like to vote about what ETI syntax you'd prefer, I've opened a poll to keep track of how many people like which syntax.
The options I've listed are limited to ones that don't break compatibility with existing code. If you'd like an option added, let me know.
https://strawpoll.com/polls/PKglzqaGJyp

There is no .member syntax in your poll (which implies deprecating existing one)

November 21, 2022
Gravatar of Walter BrightPosted by Walter Bright
in reply to Timon Gehr		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Timon Gehr


Reply
On 11/20/2022 2:03 AM, Timon Gehr wrote:
> To some extent I think this is the case, but function literals already defer the semantic pass in some way, so it seems feasible.

True, and templates also make a copy of the AST before instantiating it. But:

1. template compilation is not known for speed or low memory consumption

2. every function argument would have to be copied first, as it wouldn't know about $ processing in advance (or have to make a pass over it first to detect it)

3. if there were, say, 5 occurrences of $a, each of that which could be 2 different instances to try, what's that, 32 copies

I'm not too thrilled about this.
« First   ‹ Prev
… 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 …
Next ›   Last »