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

[Andrei Alexandrescu]

On 11/1/21 9:18 PM, deadalnix wrote:
> On Monday, 1 November 2021 at 21:41:29 UTC, Walter Bright wrote:
>> On 11/1/2021 9:18 AM, deadalnix wrote:
>>> This part IMO, point at what the #1 problem with the way things have 
>>> been done in D. D's feature just don't compose well because they 
>>> aren't orthogonal with each other (and many are inconsistent).
>>
>> Can you be more specific?
>>
> 
> Yes.
> 
> There are so many of them it's hard to list them all. I'm going to 
> glance over a bunch on the top of my mind, feel free to ask more about 
> any one of them if you want me to expand deeper.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 6. Identifier resolution and UFCS works prevent from effectively 
> extending a type's behavior. This because as soon as the type is passed 
> down to a template, then identifiers are now resolved in the template's 
> context and all the UFCS extended interface becomes impossible to resolve.
> 
> 7. Identifier resolution and mixin style codegen. mixin force a second 
> round of identifier resolution, generated via T.stringof and alike, but 
> these types may not resolve where the string is mixed in (for instance, 
> when you mixin within a template).
> 
> 8. 6 and 7 also do clash with visibility qualifiers, for the same 
> reasons. Even when symbol resolve, they may end up being private.
> 
> 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.
> 
> 11. Function and first class function are different for no good reason. 
> It's trivial to break a large portion of phobos by passing it functions 
> that are not first class.
> 
> 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.
> 
> You will note that few of the above behavior are wrong per se. They are 
> just different part of D making different assumptions about the 
> underlying reality of D, which are often fine in isolation, but are 
> mutually exclusive.
> 
> 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.
> 
> These are just a few that I can brain dump, but there are a ton more. 
> I'd say except 3. that is the elephant in the room, the overall thing is 
> more a death by a thousand cut rather than


I quote this post in its entirety because I so much agree with it. Each 
of these issues is something that has been overlooked for decades.