Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 01:39:14 UTC, Walter Bright wrote: On 4/25/2023 1:15 PM, ryuukk_ wrote: Or perhaps, listen to this person: https://github.com/dlang/dmd/pull/14650 That only does a subset of the proposal. The inference only works in specific cases. Things like function overloading are not addressed. Where were you when we discussed about it? https://forum.dlang.org/post/clkvzkxobrcqcelzw...@forum.dlang.org Nowhere to be seen For projects to move forward, discussion must happen Hiding in the back with a knife mean you waste everyone's time People who spending time thinking about the feature, writing the DIP, discussing about it, implementing the PR, arguing with people, doing the effort to argument etc etc Anyways, this is your project, you choose how it goes, it goes both ways tho, i choose what i use
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 01:26:03 UTC, Walter Bright wrote:
On 4/25/2023 4:12 PM, max haughton wrote:
I have never been in favour of D having bitfields. This isn't
worth breaking stuff for.
D bitfields didn't break anything. Also, it exposed an
overlooked bug in the ImportC bitfields.
I forgot to add a paragraph ("this" was meant to refer to the
enum changes), but any change to the grammar can break formatters
and autocomplete engines and so on - good formatters shouldn't
use an AST so bitfields in particular might have been OK but the
point stands in general.
At the moment ldc currently doesn't have bitfields so D basically
doesn't have them as a serious feature.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On 4/25/2023 1:15 PM, ryuukk_ wrote: Or perhaps, listen to this person: https://github.com/dlang/dmd/pull/14650 That only does a subset of the proposal. The inference only works in specific cases. Things like function overloading are not addressed.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On 4/25/2023 4:12 PM, max haughton wrote: I have never been in favour of D having bitfields. This isn't worth breaking stuff for. D bitfields didn't break anything. Also, it exposed an overlooked bug in the ImportC bitfields.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 22:39:35 UTC, ryuukk_ wrote: On Tuesday, 25 April 2023 at 20:59:23 UTC, max haughton wrote: On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote: On Tuesday, 25 April 2023 at 18:38:14 UTC, max haughton wrote: [...] Why you guys focus on "switch" Because that's the example given by Mike... Who doesn't love writing other than Walter Bright: [...] Who are you saying said it's too hard to implement? Also consider that *any* change breaks all the tooling. It's in the 2nd paragraph But not my paragraph? Oh, now you care about the tooling? I was the only one who raised awareness about the new features landing but tooling was ignored all while i was getting ignored (importC // dub) (bitfields // dcd), how funny I have never been in favour of D having bitfields. This isn't worth breaking stuff for. You also aren't the only one... ImportC will save everything, i now understand You're either writing past me or ascribing ideas to me that I haven't said. It may be of note that I don't work for DLF anymore
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 20:59:23 UTC, max haughton wrote: On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote: On Tuesday, 25 April 2023 at 18:38:14 UTC, max haughton wrote: [...] Why you guys focus on "switch" Because that's the example given by Mike... Who doesn't love writing other than Walter Bright: [...] Who are you saying said it's too hard to implement? Also consider that *any* change breaks all the tooling. It's in the 2nd paragraph Oh, now you care about the tooling? I was the only one who raised awareness about the new features landing but tooling was ignored all while i was getting ignored (importC // dub) (bitfields // dcd), how funny Same for the debugging issue, i got ignored Same for the TLS issue, i got ignored I has the wrong expectations it seems, you also seems to have the wrong expectation on your users ImportC will save everything, i now understand
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote: On Tuesday, 25 April 2023 at 18:38:14 UTC, max haughton wrote: [...] Why you guys focus on "switch" Because that's the example given by Mike... Who doesn't love writing other than Walter Bright: [...] Who are you saying said it's too hard to implement? Also consider that *any* change breaks all the tooling.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 18:38:14 UTC, max haughton wrote:
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:
Firstly I think this is the correct decision, certainly for
now, probably forever.
Regarding enums in switch statements, Walter suggested we
could shorten the `with final switch` syntax such that the
`with` is implicitly applied to the type of the switch
variable:
```D
auto myEnum = MyEnum.a;
with final switch (myEnum) { }
```
Alternatively, we could make the `with` implicit for case
statements, but that would break existing code.
What we have at the moment with `with` is, I think perfectly
fine.
The `switch(...) with(...)` pattern is used rather a lot in the
SDC codebase
for example and I think it's very readable.
On the topic of `with` I do think, and have even implemented
;), with expressions do need to happen eventually. The with
statement is a little heavy handed for places where these kinds
of shorthands are needed locally.
Why you guys focus on "switch"
Who doesn't love writing other than Walter Bright:
```
void set_connected()
{
network_connect_state = NetworkConnectState.CONNECTED
}
MySuperLongNameFlag flag = MySuperLongNameFlag.A |
MySuperLongNameFlag.B | MySuperLongNameFlag.C |
MySuperLongNameFlag.D;
set_flags(MySuperLongNameFlag.A | MySuperLongNameFlag.B |
MySuperLongNameFlag.C | MySuperLongNameFlag.D)
```
Too hard to implement? oh really? then i suggest trying other
languages and reading their source code, so you can learn new
techniques and improve your project
Or perhaps, listen to this person:
https://github.com/dlang/dmd/pull/14650
He seem talented, he did what you find "too hard" to implement
Being stuck is a good thing if you work, if you don't work, and
you are stuck, then perhaps is time to reflect on the time spent
working on being stuck?
I still can't debug my program btw
https://forum.dlang.org/thread/mhqywnoqhoirtruyk...@forum.dlang.org
So i now understand better, things aren't "hard to implement",
things are frozen in time, and no will to improve anything, the
motto is go template yourself! (sumtype)
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal. [snip] I didn't follow this too closely last year, but I don't see a lot wrong with the "implicit with" approach (or at least I'm not sure how wrong it would be, I would lean toward adding it to a preview switch and see if it broke anything). The DIP proponents would argued against that approach seem to just be saying that the DIP is more powerful than that. Sure, that may be true, but this is also a situation where they probably shouldn't let perfect be the enemy of good. I'd rather "implicit with" than using strings and mixins to hack together the same effect for function argument lists.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:
Firstly I think this is the correct decision, certainly for now,
probably forever.
Regarding enums in switch statements, Walter suggested we could
shorten the `with final switch` syntax such that the `with` is
implicitly applied to the type of the switch variable:
```D
auto myEnum = MyEnum.a;
with final switch (myEnum) { }
```
Alternatively, we could make the `with` implicit for case
statements, but that would break existing code.
What we have at the moment with `with` is, I think perfectly fine.
The `switch(...) with(...)` pattern is used rather a lot in the
SDC codebase
for example and I think it's very readable.
On the topic of `with` I do think, and have even implemented ;),
with expressions do need to happen eventually. The with statement
is a little heavy handed for places where these kinds of
shorthands are needed locally.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal. IMO this is the correct decision. While a feature like this would be nice to have, it's not of critical importance, so we can afford to have high standards for the quality of the proposal. During the review process, there was some discussion in the community Discord about generalizing this idea, of literals with "holes" that the compiler can fill in, to other types of data beyond just enums. Perhaps it could even be unified with pattern matching--e.g., you could use a pattern as a literal outside of a `switch` or `match` statement, and the compiler would attempt to fill it in based on the context. I can't say with confidence that such a proposal would be accepted (the concerns about top-down vs bottom-up inference still apply), but I personally would be excited to see one.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:
I submitted DIP1044, "Enum Type Inference", to Walter and Atila
on April 1. I received the final decision from them on April
18. They have decided not to accept this proposal.
https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1044.md
The said the proposal was well done and an interesting read,
but found it to be too complex for insufficient benefit. They
provided the following list of concerns that led them to their
decision:
* Given that D already has `with`, `alias`, and `auto`, it does
not seem worthwhile to add a special case for enums.
* Semantic analysis in D is strictly bottom-up. This proposal
would add top-up type inference on top of that. This presents
problems in handling function and template overloads, as well
as variadic parameter lists.
* The proposal only allows ETI in some contexts. This is
potentially confusing for the programmer, particularly in the
presence of mixin templates (which draw symbols from the
instantiation context) and function overloads.
* Symbol tables can get very large. Lookups are done via hash
table for max speed, but this will not work for ETI. There may
be a very large number of "enums in scope", and each one will
have to be searched to resolve a member.
* ETI is similar to ADL (Argument Dependent Lookup) in C++.
Walter implemented ADL in the Digital Mars C++ compiler and is
strongly against allowing anything like it in D. He finds it
slow and complex, and few people really know how it's going to
work.
Regarding enums in switch statements, Walter suggested we could
shorten the `with final switch` syntax such that the `with` is
implicitly applied to the type of the switch variable:
```D
auto myEnum = MyEnum.a;
with final switch (myEnum) { }
```
Alternatively, we could make the `with` implicit for case
statements, but that would break existing code.
I'm a little glad for reading and reviewing code that this didn't
get through, at least without IDE, but I think this would have
been quite a useful feature for writing code.
However I think we probably should still implement this in DCD /
have better auto-suggest according to the rules here. I think it
will be similarly useful having better auto-complete suggestion
contexts compared to having new syntax in the language. (maybe
being able to trigger it explicitly using $ at the start, but
definitely want to have these suggestions being prioritized)
Re: DIP1044---"Enum Type Inference"---Formal Assessment
This is not good news :-|
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal. That DIP sure became a bikeshed at the last review. Good effort from you and Aya to revise and submit it regardless. Note though, the links to the community review currently point to ProtoObject DIP review.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 06:41:04 UTC, zjh wrote: Is it okay to use a new keyword `enumswitch` that is equivalent to `with final switch`? If there were an `official restriction` that could simplify `long keywords`, that would be great,like: ```d alias keyword enumswitch=with final switch; ``` Multiple `keywords/@property` can also be simplified (`pure/@ nogc/@ safe/public/...`), but it is best to only allow `official simplification`, otherwise it will mess up the grammar.
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: .. Is it okay to use a new keyword `enumswitch` that is equivalent to `with final switch`?
