I find that there's too much going on in a single line now. With the
extra "type" keyword, my mind gets stuck figuring out precedence rules.
I agree, its hard to read and too much to type from my perspective.
For "switch" that would imply:
case c as count:
Is that any easier for the parser?
If not, would just
type count as c:
do the job? Although it mixes LHS and RHS again, it seems intuitive to
me. Finally it would be a tradeoff between ordering consistency and a
third keyword (like "->" or "in").
However, introducing tuples is a major piece by itself, and I'm
reluctant to have the Broker changes depend on that.
We could go the Broker::status() route for now and switch over to
tuples later if/when we get them ...
Seems reasonable to me. However, I thought adding tuples would be
relatively straight forward, given that there are already some similar
structures in use. Is there a major show-stopper I am missing or is it
just the fact that tuple support would be a new/untested language feature?
We'd need to hook them into a number of places across the interpreter.
For example there are various locations where types coerce
automatically on assignment & parameter passing; tuples would need to
do the right thing there (and recursively). Also, the current ad-hoc
tuple-like constructs would need to be adapted, and maybe some more
similar constructs added elsewhere for added flexibility. It's not
rocket science, it just needs somebody to take it on as a separate
project I think.