On Wed, 22 Feb 2023 at 12:06, Christoph Meyer
<christoph.meyer.2006_at_[hidden]> wrote:

> 3) This is not specific to this proposal. Imagine a series of functions called in a chain which all take in a non-const glvalue and modify its value. If you declare the input value -- which is declared in another file far away -- const, everything breaks. If you wanted to double-ensure the typeness of a dependent name, you could still use the `typename` keyword.
>
> I can totally understand your concerns about code clarity and readability but i think they don't justify forcing the programmer to introduce redundancy that could be avoided (like making the `override` keyword obligatory).
> In my opinion, if you find yourself in the situation where it would be ambiguous if a name describes a type or a value, the problem lies in your code, not in the language itself.

Well, the concern in (3) isn't about cases where action-at-a-distance
makes your code ill-formed. It's about cases where your code
continues to compile, but with a different meaning.

> 2) see 1)

I don't see how (1) addresses (2). When a template is parsed, a
compiler doesn't need to do name lookup to figure out whether
a name is a type or a variable. Now it does, it needs to look at
whether our template is constrained, and then look into the
definitions
of the constraints and find type requirements for the name, just to be
able to parse subsequent uses of the name, at the time the template is
parsed, regardless of whether
it's used, and regardless of whether all of the constraint definitions
end up being used. Right now, a compiler doesn't need to look
at constraint definitions at all during parsing of a template, it'll
need to do that later, when a specialization is instantiated.

So this proposal has both an additional name lookup cost, and the cost
of scanning constraint definitions for potential occurrences
of type requirements that match the name we're looking up, and both of
those costs are incurred when the template is parsed,
not when it's used.