Here is something I've noticed going on various time, recently in the memory management threads, but as to avoid an already heated debate, I'll use enum types as an example.

We have a problem with the way enums are defined. If you have :

enum E { A, B, C }
E e;

We have (1)
final switch(e) with(E) {
    case A:
        // ...
    case B:
        // ...
    case C:
        // ...
}

But also have (2):
typeof(E.A | E.B) == E

When raising this, the discussion goes as follow
 - "If you have (1), we can't have (2), as break guarantee (1) rely on."
 - "(2) is usefull. For instance UserID or Color"
 - "Then let's get rid of (1)"
 - "(1) is useful, for instance to achieve X or Y"
 - "Let's create a new type in the language, (1) would be enum and (2) would be this new type"
 - "It adds too much complexity in the language"

This very conversation went on in a very lengthy thread a while ago (note, for SDC, I just dropped (2), typeof(E.A | E.B) == int and I consider it a closed issue).

It can go forever, as all reason given for every concern raised is valid. Yes, adding a new type is probably too much for the benefit, yes (1) and (2) are useful in various scenarios. And, by refusing to take a step back look at the problem as a whole, we can turn around forever and never conclude anything, benefiting only the status quo.

I've seen this attitude going on on various topics. This is the surest and fastest way to end up with C++ without the C source compatibility. I'd like that we just stop this attitude.

On 2015-02-25 22:06, deadalnix wrote:
> Here is something I've noticed going on various time, recently in the
> memory management threads, but as to avoid an already heated debate,
> I'll use enum types as an example.
>
> We have a problem with the way enums are defined. If you have :
>
> enum E { A, B, C }
> E e;
>
> We have (1)
> final switch(e) with(E) {
>      case A:
>          // ...
>      case B:
>          // ...
>      case C:
>          // ...
> }
>
> But also have (2):
> typeof(E.A | E.B) == E

How about allowing something like this:

enum E : void { A, B, C }

The above would disallow use case (2). The compiler would statically make sure a variable of type "E" can never have any value other than E.A, E.B or E.C.

This should be completely backwards compatible since the above syntax is currently not allowed. It also doesn't introduce a new type, at least not syntactically.

-- 
/Jacob Carlborg

On Wednesday, 25 February 2015 at 21:06:54 UTC, deadalnix wrote:
> This very conversation went on in a very lengthy thread a while ago (note, for SDC, I just dropped (2), typeof(E.A | E.B) == int and I consider it a closed issue).

If you keep the type, you can decompose the flag set when converting the value to string, see how C# does it: https://msdn.microsoft.com/en-us/library/vstudio/system.flagsattribute.aspx

On Wednesday, February 25, 2015 21:06:53 deadalnix via Digitalmars-d wrote:
> Here is something I've noticed going on various time, recently in the memory management threads, but as to avoid an already heated debate, I'll use enum types as an example.
>
> We have a problem with the way enums are defined. If you have :
>
> enum E { A, B, C }
> E e;
>
> We have (1)
> final switch(e) with(E) {
>      case A:
>          // ...
>      case B:
>          // ...
>      case C:
>          // ...
> }
>
> But also have (2):
> typeof(E.A | E.B) == E
>
> When raising this, the discussion goes as follow
>   - "If you have (1), we can't have (2), as break guarantee (1)
> rely on."
>   - "(2) is usefull. For instance UserID or Color"
>   - "Then let's get rid of (1)"
>   - "(1) is useful, for instance to achieve X or Y"
>   - "Let's create a new type in the language, (1) would be enum
> and (2) would be this new type"
>   - "It adds too much complexity in the language"
>
> This very conversation went on in a very lengthy thread a while
> ago (note, for SDC, I just dropped (2), typeof(E.A | E.B) == int
> and I consider it a closed issue).
>
> It can go forever, as all reason given for every concern raised is valid. Yes, adding a new type is probably too much for the benefit, yes (1) and (2) are useful in various scenarios. And, by refusing to take a step back look at the problem as a whole, we can turn around forever and never conclude anything, benefiting only the status quo.
>
> I've seen this attitude going on on various topics. This is the surest and fastest way to end up with C++ without the C source compatibility. I'd like that we just stop this attitude.

Personally, I think that the status quo with enums is horrible and that no operation should be legal on them which is not guaranteed to result in a valid enum value and that if you want to create a new type that can have values other than those enumerated, you create a struct with some predefined static values and don't use enums at all, but others disagree vehemently (Andrei included). However, as it stands - as you point out - final switch is completely broken, which is not a subjective issue at all but rather quite an objective one. The solution that was proposed (by Andrei I think) the last time that I was in a discussion on that was to introduce the concept of "final enums" so that if you do something like

final enum E { A, B, C }

it's then the case that no operation on E is legal unless it's guaranteed to result in an E (with casting being the way out when required, of course), and then we would move towards making final switch illegal on normal enums. I was going to create a DIP for it but forgot. I still think that it's something that needs to be resolved though, since otherwise, enums are ugly to work with (subjective though that may be), and final switch is broken.

- Jonathan M Davis

On Thursday, 26 February 2015 at 09:49:26 UTC, Jonathan M Davis wrote:
> On Wednesday, February 25, 2015 21:06:53 deadalnix via Digitalmars-d wrote:

>> I'll use enum types as an example.
<snip>
>> I've seen this attitude going on on various topics. This is the
>> surest and fastest way to end up with C++ without the C source
>> compatibility. I'd like that we just stop this attitude.

> Personally, I think that the status quo with enums is horrible ...

I think the real problem goes clearly beyond enums, it's an overall approach to changes in the D language itself.

I join to deadalnix's worries.

---
Paolo

On Thursday, 26 February 2015 at 11:10:16 UTC, Paolo Invernizzi wrote:
> I think the real problem goes clearly beyond enums, it's an overall approach to changes in the D language itself.
>
> I join to deadalnix's worries.
>
> ---
> Paolo

Yes, I don't care about the specific enum case, in fact, that is one of the least offender and this is why I choose it as an example here.

What worries me is that whatever way you take the problem there is a good reason not to proceed. And, taken independently, every one of these reason are valid, or at least something reasonable people can agree upon.

But there is no way we can agree on all of these at once.

On Thursday, February 26, 2015 20:35:02 deadalnix via Digitalmars-d wrote:
> On Thursday, 26 February 2015 at 11:10:16 UTC, Paolo Invernizzi wrote:
> > I think the real problem goes clearly beyond enums, it's an overall approach to changes in the D language itself.
> >
> > I join to deadalnix's worries.
> >
> > ---
> > Paolo
>
> Yes, I don't care about the specific enum case, in fact, that is one of the least offender and this is why I choose it as an example here.
>
> What worries me is that whatever way you take the problem there is a good reason not to proceed. And, taken independently, every one of these reason are valid, or at least something reasonable people can agree upon.
>
> But there is no way we can agree on all of these at once.

Well, I suspect that each case would have to be examined individually to decide upon the best action, but I think that what it comes down to is the same problem that we have with getting anything done around here - someone has to do it. For instance, we all agree that std.xml needs to be replaced with something range-based and fast rather than what we currently have, but no one has made the time or put forth the effort to create a replacement and get it through the review process. Someone has to step up and do it, or it'll never get done.

With language changes, it's often the same. Someone needs to come up with a reasonable solution and then create a PR for it.  They then have a much stronger position to argue from, and it may get in and settle the issue. And it may not get merged, because it still can't be agreed upon as the correct solution, but an actual implementation carries a lot more weight than an idea, and in most of these discussions, we just discuss ideas without actually getting the work done. If we want stuff like this to get done then more of us need to find the time and put forth the effort to actually do it and be willing to have put forth the time and effort only to have our work rejected. But many of us are very busy, and we've failed to attract enough new contributors on big stuff to get many big things done by folks who haven't been doing a lot already. We probably need to find a way to encourage folks to do bigger things than simply making small improvements to Phobos - be it writing a potential, new module for Phobos or be it implementing critical stuff in the compiler.

- Jonathan M Davis

On Friday, 27 February 2015 at 01:33:58 UTC, Jonathan M Davis wrote:
> Well, I suspect that each case would have to be examined individually to
> decide upon the best action, but I think that what it comes down to is the
> same problem that we have with getting anything done around here - someone
> has to do it.

This isn't true at all. Things need to be approved first, then implemented.

> With language changes, it's often the same. Someone needs to come up with a
> reasonable solution and then create a PR for it.  They then have a much
> stronger position to argue from, and it may get in and settle the issue.

I sometimes feel so bad for Kenji, who has come up with several reasonable solutions for longstanding problems, *and* implemented them, only to have them be frozen for *years* by indecision at the top. I'll never believe your side until this changes. You can see exactly how D works by looking at how Kenji spends his time. For a while he's only been fixing ICEs and other little bugs which he knows for certain will be accepted. I'm not saying any of these top level decisions are easy, but I don't believe you for a second, at least when it comes to the language itself. Phobos may be different.

On 2/26/15 5:48 PM, Zach the Mystic wrote:
> I sometimes feel so bad for Kenji, who has come up with several
> reasonable solutions for longstanding problems, *and* implemented them,
> only to have them be frozen for *years* by indecision at the top.

Yah, we need to be quicker with making decisions, even negative. This requires collaboration from both sides - people shouldn't get furious if their proposal is rejected. Kenji has been incredibly gracious about this. -- Andrei

On Friday, February 27, 2015 01:48:00 Zach the Mystic via Digitalmars-d wrote:
> On Friday, 27 February 2015 at 01:33:58 UTC, Jonathan M Davis wrote:
> > Well, I suspect that each case would have to be examined
> > individually to
> > decide upon the best action, but I think that what it comes
> > down to is the
> > same problem that we have with getting anything done around
> > here - someone
> > has to do it.
>
> This isn't true at all. Things need to be approved first, then implemented.

If something is implemented, then there's an actual implementation to discuss and accept or reject, and sometimes that leads to the problem getting resolved, whereas just discussing it frequently just results in discussion rather than anything actually happening. Sure, if a decision isn't made before something is implemented, then the odds of it getting rejected are higher, and that can be very frustrating, but sometimes, it's the only way that anything gets done.

> > With language changes, it's often the same. Someone needs to
> > come up with a
> > reasonable solution and then create a PR for it.  They then
> > have a much
> > stronger position to argue from, and it may get in and settle
> > the issue.
>
> I sometimes feel so bad for Kenji, who has come up with several reasonable solutions for longstanding problems, *and* implemented them, only to have them be frozen for *years* by indecision at the top. I'll never believe your side until this changes. You can see exactly how D works by looking at how Kenji spends his time. For a while he's only been fixing ICEs and other little bugs which he knows for certain will be accepted. I'm not saying any of these top level decisions are easy, but I don't believe you for a second, at least when it comes to the language itself. Phobos may be different.

Yes. Sometimes stuff gets rejected or stuck in limbo, but there's been plenty that has gotten done because someone like Kenji just decided to do it. The fact that stuff is stuck in limbdo for years is definitely bad - no question about it - but so much more wouldn't have been done had no one at least implemented something and tried to get it into the compiler or the standard library - especially when you're talking about the compiler. Language discussions frequently never result in anything, whereas creating a PR for dmd will sometimes put things in a position where Walter finally approves it (or rejects it) rather than simply discussing it and getting nowhere.

- Jonathan M Davis