Menu
Search

Forums

Forum Index

July 21, 2021
Gravatar of Walter BrightPosted by Walter Bright
in reply to Petar Kirov [ZombineDev]		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Petar Kirov [ZombineDev]


Reply
On 7/21/2021 8:13 AM, Petar Kirov [ZombineDev] wrote:
> similar to how struct literals are allowed only for [variable initialization][3]

Struct literals can be anywhere once named parameters are implemented. They already can be if you don't need to use named parameters.
July 21, 2021
Gravatar of Adam D RuppePosted by Adam D Ruppe
in reply to Walter Bright		Reply
Adam D Ruppe
Gravatar of Adam D Ruppe
Posted in reply to Walter Bright


Reply
On Wednesday, 21 July 2021 at 23:00:06 UTC, Walter Bright wrote:
> Just use it right after the declaration of the enum.

That limits the usefulness, but you still might as well do it right since then it works anywhere.

>> It doesn't get closer to the Swift examples.
>
> How so?

Consider:

import a;
import b;

foo(something);
bar(something);

foo and bar take different types that both have a member something. the swift examples resolve correctly. This does not and requires disambiguation on both uses.
July 21, 2021
Gravatar of Walter BrightPosted by Walter Bright
in reply to Adam D Ruppe		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Adam D Ruppe


Reply
On 7/21/2021 4:32 PM, Adam D Ruppe wrote:
> Consider:
> 
> import a;
> import b;
> 
> foo(something);
> bar(something);
> 
> foo and bar take different types that both have a member something. the swift examples resolve correctly. This does not and requires disambiguation on both uses.

True, but that isn't specific to enums. D does not attempt to do overloading on anything but functions & templates. Implementing russhy's proposal won't change that.
July 21, 2021
Gravatar of Walter BrightPosted by Walter Bright
in reply to Steven Schveighoffer		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to Steven Schveighoffer


Reply
On 7/21/2021 2:16 PM, Steven Schveighoffer wrote:
> No, `mixin something; thenCallFunction(...);` isn't even close to the same.

I don't know what it is you're asking for, then.
July 22, 2021
Gravatar of zjhPosted by zjh
in reply to Walter Bright		Reply
zjh
Gravatar of zjh
Posted in reply to Walter Bright


Reply

On Wednesday, 21 July 2021 at 21:04:56 UTC, Walter Bright wrote:

>

On 7/21/2021 12:08 PM, russhy wrote:

> >

And the default constructor,
Why can't it like C++: T t; That's all.
Many C++ programmers want to have constructors like C++ as T t{...};.

 >

It's been discussed many times. It comes up once a year or so.

I really don't understand. Isn't d called pragmatism?

That's so much a little bit of improvement, d can attract a bunch of c++ people, and I don't know why not to do it?

Some people say that when using d, the friction force is small. Since this is an advantage, why not strengthen it?

For the so-called consistency? Are you not against what is called consistency?

July 22, 2021
Gravatar of Paul BackusPosted by Paul Backus
in reply to zjh		Reply
Paul Backus
Gravatar of Paul Backus
Posted in reply to zjh


Reply

On Thursday, 22 July 2021 at 01:12:40 UTC, zjh wrote:

>

On Wednesday, 21 July 2021 at 21:04:56 UTC, Walter Bright wrote:

>

On 7/21/2021 12:08 PM, russhy wrote:

> >

And the default constructor,
Why can't it like C++: T t; That's all.
Many C++ programmers want to have constructors like C++ as T t{...};.

 >

It's been discussed many times. It comes up once a year or so.

I really don't understand. Isn't d called pragmatism?

That's so much a little bit of improvement, d can attract a bunch of c++ people, and I don't know why not to do it?

Some people say that when using d, the friction force is small. Since this is an advantage, why not strengthen it?

For the so-called consistency? Are you not against what is called consistency?

Initialization in C++ is described as a "nightmare" by experienced C++ programmers [1]. This is probably not something that D would benefit from imitating.

[1] https://www.youtube.com/watch?v=7DTlWPgX6zs

July 22, 2021
Gravatar of zjhPosted by zjh
in reply to Paul Backus		Reply
zjh
Gravatar of zjh
Posted in reply to Paul Backus


Reply

On Thursday, 22 July 2021 at 01:40:07 UTC, Paul Backus wrote:

>

On Thursday, 22 July 2021 at 01:12:40 UTC, zjh wrote:

>

On Wednesday, 21 July 2021 at 21:04:56 UTC, Walter Bright

I am also experienced C++ Programmer,why I don't hurt from it?

July 22, 2021
Gravatar of DukcPosted by Dukc
in reply to russhy		Reply
Dukc
Gravatar of Dukc
Posted in reply to russhy


Reply

On Tuesday, 20 July 2021 at 15:50:49 UTC, russhy wrote:

>

So what do you think? yay? nay? why not?

As mentioned by others, enumVar = .memberName is ambiguous with the module scope operator. If you want to pursue this, might I recommend enumVar = "memberName" instead? You still need no new syntax, and it could be implemented with value range propagation mechanics. This way:

If a string, wstring or dstring str that is known at compile time, is assigned to value of enumerated type ET, it is interpreted as assigning mixin("ET." ~ str) to the assignee value.

July 22, 2021
Gravatar of Paul BackusPosted by Paul Backus
in reply to Dukc		Reply
Paul Backus
Gravatar of Paul Backus
Posted in reply to Dukc


Reply

On Thursday, 22 July 2021 at 03:21:06 UTC, Dukc wrote:

>

On Tuesday, 20 July 2021 at 15:50:49 UTC, russhy wrote:

>

So what do you think? yay? nay? why not?

As mentioned by others, enumVar = .memberName is ambiguous with the module scope operator. If you want to pursue this, might I recommend enumVar = "memberName" instead? You still need no new syntax, and it could be implemented with value range propagation mechanics. This way:

If a string, wstring or dstring str that is known at compile time, is assigned to value of enumerated type ET, it is interpreted as assigning mixin("ET." ~ str) to the assignee value.

 
enum E : string { x = "y", y = "x" }

E e = "y"; // what happens here?
July 22, 2021
Gravatar of Mathias LANGPosted by Mathias LANG
in reply to Walter Bright		Reply
Mathias LANG
Gravatar of Mathias LANG
Posted in reply to Walter Bright


Reply

On Wednesday, 21 July 2021 at 06:19:20 UTC, Walter Bright wrote:

> >

The only time I had found enums to be too verbose is in switch statements.
As mentioned previously, switch (value) with (EnumType)` helps.

Yup.

>

I think we should make it the default (essentially cases should be in a with (typeof(value)) scope), and that would alleviate most of the pain.

Sorry, I'm not understanding the pain.

What I meant was that instead of recommending our users to use switch (value) with (EnumType)`, we could just make it the default since it's the common case with enums. Unless we think that requiring the type of the enum be spelt out is better.

It could add to the long list of those usability enhancements that are a hallmark of D (like _ in number literals). I personally don't mind the verbosity, but I heard this complaint a few times over the years.

« First   ‹ Prev
1 2 3 4 5 6 7 8
Next ›   Last »