well, technically, if u wanted to "simply call a function and not care about what was passed in", u had to have defined a
variadic sink as the function's last argument.
u didnt have to do this for callbacks, function references and the like. now u do
does it make sense these two to behave differently:
Code: Select all
greet() {
MsgBox 'hello'
}
greet('garbage', 'goes', 'in') ; throws
fn := Func('greet')
%fn%('garbage', 'goes', 'in') ; this is ok, though
i get that its convenient/flexible as u put it when it comes to working with guis, but i have to question the degree to which having to punch out an additional asterisk impairs this supposed flexibility
at the end of the day its gonna be a trade-off between flexibility/convenience and consistency/correctness
idk what to make of
@lexikos's considerations of allowing
=> expr. this seems like its introducing just another special case. whats the equivalent if the handler was a normal function? there isnt any, ud have to write
*. if the parser can be made to handle
* => expr as
@Helgef suggests, without any ambiguities, i think this could be acceptable, since
arg1 => expr is a thing already.
or maybe the gui system can be changed to only pass in as many parameters as the handler defines and keep the pre-103 syntax, but will yet again end up being just another special case and it will only work for the gui system and not any user-defined stuff
or maybe the pendulum could swing the other way entirely? keep everything as it used to be and lift the restrictions on
functions requiring an exact amount of parameters??
the way it is now makes the most sense to me. if the asterisk is that much of a hindrance u could always make a macro for it