Herb Sutter's CppCon talk "Extending and Simplifying C++: Thoughts on Pattern Matching using `is` and `as`"

[Walter Bright]

Thank you. This is a great list. I would appreciate it if you could make a 
bugzilla entry for each one, along with a piece of example code.

Some specific comments below:

On 11/1/2021 6:18 PM, deadalnix wrote:
> 1. enum binary ops and final switch. final switch assume an enum take a finite 
> set of values as declared in the enum, but many more value can be obtained using 
> binary ops.

Not sure what to say here. enums have more than one use:

1. enumerate all values of a particular type
2. enumerate some specific values of a particular type

Only use final for case (1).

> 2. type qualifier and delegates. Because the type system doesn't track the type 
> qualifier of its capture, it is possible to have immutable or shared data refers 
> to thread local ones through a delegate.

This is simply a bug I haven't gotten around to fix.


> 3. type qualifier transitivity and templates. template will consider types with 
> different qualifier as disjoint, which seems like they should, until you try to 
> write a container library or try to get range to interract with type qualifier.
> 
> This one is IMO the #1 problem with D, hands down. Nothing comes even remotely 
> close. We don't have a decent set of collection to use because of it, and even 
> worse, it's not even possible to write one.

I beg of you and Andrei to produce a canonical example and place it in bugzilla. 
Perhaps I misunderstood Andrei when he said it would be resolved when we had 
copy constructors. Well, we have copy constructors now.


> 4. Scope variables and closures. Closure capture sub scopes incorrectly. This is 
> especially relevant in loops, because the variables captured are past their 
> lifetime, leading to incorrect behaviors.
> 
> 5. string autodecoding. The array type that behave like no other.

That's actually not a problem with the language. It's a problem with Phobos, one 
I've been trying to kill with fire for 10 years no.


> 9. Functional programming and attribute soup. Because it is not possible to 
> define attribute in a way that depends to functions passed as argument, it is 
> not possible to compose anything in a functional way without assuming that 
> everything is impure, throw and uses the GC and more.
> 
> This breaks inout in an unfixable manner as it becomes impossible to disambiguate:
> 
> X foo(inout(Y) bar(...)) {} // Is the inout qualifier related to X or to bar's 
> argument? Or both?
> 
> 10. shared things are not constructible. dlang.org literally say you got to cast 
> shared in and out, which is actually UB.

Yes, that's correct. I know of *no* way to construct a shared object without 
going into @system code. Just like there's no way to implement malloc() without 
dirty pointer manipulation. Note that in @safe code neither can be done. I 
propose that this is not a further issue.


> 12. Sometime bool are integrals, sometime they aren't. Bonus point: one of the 
> part of D that think bool are integral is DMD, and DMD won't hesitate to convert 
> ints to bool if it can constant fold them into 0 or 1. But `isIntegral!bool` is 
> false for instance.

Phobos has a number of incomprehensible isxxxxx() functions. They are not the 
language's fault, though. Nor are they my fault, as I never reviewed them. But 
they are my responsibility.


> For instance, there are good reasons for a bool to be an integral, and good 
> reasons for it not to be. But there are no good reasons for DMD doig implicit 
> conversion to bool as if was an integral, and `isIntegral!bool` being false. 
> Each of them can be true, but both of them cannot be true at the same time.

Of course. Part of the motivation for Phobos v2 is to get rid of that garbage.