Date: Fri, 15 Apr 2022 22:34:39 +0100
On 4/15/22, Jason McKesson via Std-Proposals wrote:
> Just to be clear, my point was not specifically about complexity added
> to compilers. I was referring to complexity added to the *language*.
>
> First, you're overloading keywords with new functionality that is at
> best marginally based on the literal text of the keyword. Just try to
> explain to someone how "requires continue" relates to the usual
> meaning of "requires" in that position of a function declaration.
>
> Second, it creates very strange control-flow dynamics, where the
> presence of a keyword outside of the body of the function causes other
> functions to be called when you call that function. That's similar to
> calling constructors of subobjects, but it's still really bizarre (and
> it doesn't use member initialization list syntax).
People use words like 'strange', 'weird' and 'bizarre' as synonyms for
'new'. What I'm proposing is simply a new idea, something that hasn't
been done before. Speaking in a very generic sense, humankind
shouldn't be reluctant to make progress simply because of how we used
to do things. For a long time I've thought that one of the most
dangerous phrases in the English language is "because that's how we've
always done it".
Object-orientated programming was 'bizarre' at one point, but it
caught on eventually. Maybe these new continuity methods I'm proposing
will catch on too if people think they makes sense and they reduce
work and reduce human error.
> Third, there are multiple interactions between keywords that make
> understanding what's going on difficult. For example, the behavior of
> `continue` prefixed by `requires` is completely different from the
> behavior of `continue` alone.
The actual keywords chosen for the final proposal isn't of much
importance to me. I'm sure if I sat down with a pen and paper for ten
minutes a day I could come up with all sorts of intriguing
combinations like "extern goto" or "extern++" or whatever. The choice
of keyword combinations to use isn't a sticking point. And of course
there's also the option of having an 'identifier with special meaning'
instead of re-using a keyword (similar to the way in which "final" is
not a keyword).
> The feature is complicated, not because it's hard to implement, but
> because of what it is doing. It's doing something complicated, novel,
> and uses keywords in a novel way to do it.
It's not nearly as complicated as implementing virtual functions with
V-tables. Actually just now I had a pretty gnarly idea.... I could
create a V-table that instead of having just one function pointer for
each entry, it has a linked list of function pointers for each entry.
So then when you invoke a virtual method, all of the function pointers
in the linked list in the V-table are invoked. But that would be a
separate proposal (I'll start a new document for it just in case).
> Just to be clear, my point was not specifically about complexity added
> to compilers. I was referring to complexity added to the *language*.
>
> First, you're overloading keywords with new functionality that is at
> best marginally based on the literal text of the keyword. Just try to
> explain to someone how "requires continue" relates to the usual
> meaning of "requires" in that position of a function declaration.
>
> Second, it creates very strange control-flow dynamics, where the
> presence of a keyword outside of the body of the function causes other
> functions to be called when you call that function. That's similar to
> calling constructors of subobjects, but it's still really bizarre (and
> it doesn't use member initialization list syntax).
People use words like 'strange', 'weird' and 'bizarre' as synonyms for
'new'. What I'm proposing is simply a new idea, something that hasn't
been done before. Speaking in a very generic sense, humankind
shouldn't be reluctant to make progress simply because of how we used
to do things. For a long time I've thought that one of the most
dangerous phrases in the English language is "because that's how we've
always done it".
Object-orientated programming was 'bizarre' at one point, but it
caught on eventually. Maybe these new continuity methods I'm proposing
will catch on too if people think they makes sense and they reduce
work and reduce human error.
> Third, there are multiple interactions between keywords that make
> understanding what's going on difficult. For example, the behavior of
> `continue` prefixed by `requires` is completely different from the
> behavior of `continue` alone.
The actual keywords chosen for the final proposal isn't of much
importance to me. I'm sure if I sat down with a pen and paper for ten
minutes a day I could come up with all sorts of intriguing
combinations like "extern goto" or "extern++" or whatever. The choice
of keyword combinations to use isn't a sticking point. And of course
there's also the option of having an 'identifier with special meaning'
instead of re-using a keyword (similar to the way in which "final" is
not a keyword).
> The feature is complicated, not because it's hard to implement, but
> because of what it is doing. It's doing something complicated, novel,
> and uses keywords in a novel way to do it.
It's not nearly as complicated as implementing virtual functions with
V-tables. Actually just now I had a pretty gnarly idea.... I could
create a V-table that instead of having just one function pointer for
each entry, it has a linked list of function pointers for each entry.
So then when you invoke a virtual method, all of the function pointers
in the linked list in the V-table are invoked. But that would be a
separate proposal (I'll start a new document for it just in case).
Received on 2022-04-15 21:34:41