On 27/08/2024 12:56, Derick Rethans wrote:
Using 'default' as a place holder for (not) passing an argument seems
useful. I am however much uncertain about using composition with the
keyword in expressions.
Presumably you mean ternary and null coalesce would still be acceptable?
Otherwise, it is little more than an alternative to named parameters,
which is seldom useful. Ternary and null coalesce are, themselves,
expressions so I expect that is why I was guided towards treating
`default` the same way. Whilst the applications beyond use in
conditionals still strikes me as limited, it also appears equally
harmless. Though the number of people whom feel its use in expression
should be limited is steadily growing, I'm still waiting on someone to
publish an exclusion list with justification for each exclusion, because
again, I think a plurality of possibilities are harmless. Nevertheless,
an inclusion list was produced by IMSoP, based on what he felt would be
useful, but I think arbitrary exclusions are unintuitive for developers
and likely to limit someone from doing something justifiably useful that
we didn't conceive at the time.
I also think that implementation would probably be significantly less
complex as it was only used for placeholders.
Would it? I was told that the alternative was to modify all the SEND
opcodes, which is anything but less complex. The current implementation
seems necessarily simple to me since it just adds a single new opcode
that doesn't interfere with anything else. I say necessarily, because if
it was actually complex, I probably couldn't have written the solution
given my limited ability.
It's likely something that can be handled in the parser.
Clearly this problem cannot be solved solely in the parser. If I assume
you're proposing to just allow `default` in conditionals, what is
responsible for compiling that and how will the called function know
what to do with it?
Cheers,
Bilge
