Jon Lang wrote:
Invocants:
* Is it illegal to specify an invocant in a sub, or is it merely
nonsensical? That is, should the compiler complain, or should it
silently treat the invocant as the first positional parameter? (The
latter has the advantage that you don't have to worry about what the
signature is being used for; it has the disadvantage of being, well,
nonsensical: invocants are meaningless without the context of a method
- and /maybe/ a role - to provide them meaning.)
I'd think it was an error at compile time. We can easily detect it.
* Likewise, if I interpolate a signature with an invocant into another
signature (somewhere other than at the start), is this an error, or
will the invocant be silently converted into an ordinary positional
parameter?
I think if the condition from above would check we are being used to
define a signature for a method, that would make this case an error too.
I can't immediately think of a use case for making an exception for a
signature written elsewhere having one, but somebody else maybe can.
* What types are you allowed to assign to an invocant?
Any that you like, but you might find a lot of people yelling the word
"Liskov" at you, or create a method that's impossible to call. ;-)
* Does anyone object to roles having an invocant, and that invocant
referring to the class that is doing the role?
Yes; on further reflection, the ability to type that invocant raises all
kinds of possible WTFs without a good enough use case. So I'd really
rather we don't go down this road.
Longnames:
* Why are we using ";;" to denote the end of a multi function's
longname? I'm thinking that doubling up on the normal delimiter may
make more sense - which would normally mean ",,", but would mean ";;"
if you're using a multidimensional argument list and the longname ends
where a semicolon would normally go.
Think it's probably a visual argument - ,, just doesn't stand out as
"there's something different going on here" sufficiently.
* Can any required parameter be part of the longname, or are only
positional parameters allowed? (I'm expecting the latter; but I'd
like confirmation.)
Only positional parameters participate in multiple dispatch in Perl
6.0.0, so yes, the latter.
* Are placeholder parameters ever considered to be part of a
function's longname? (I'm expecting that they aren't: if you want a
longname, you ought to specify it in a formal signature.)
Placeholder parameters result in a signature being generated based upon
them, as far as I can tell (and so far as we've implemented in Rakudo).
So yes, they would all count in the long name - or at least, the
positional ones. Also note that if you do have placeholder parameters
it's illegal to write a signature on the block too.
Starting and Ending delimiters:
* Why are pointy blocks forbidden from enclosing their signatures in
parentheses, or from using the ":( ... )" notation? Is this a
holdover from the early days, when parentheses denoted a list? Or is
there still a good reason not to allow such notation?
Really not sure on this one.
* Why do parameterized roles use "[ ... ]" for their signatures
instead of ":( ... )" or "( ... )"?
RoleName(...) is a type coercion, so we can't use that. I also think
it's good that parametrized types have something visually distinctive
about them, though, so I think the current syntax is probably just fine.
Named parameters:
* Must required named parameters be defined before optional named
parameters are, or are we allowed to interleave the two?
As far as I know, you can mix them for named (but not, obviously, for
positional).
Placeholder parameters:
* does the use of placeholder parameters interfere with the use of the
slurpy parameters normally provided by the default signature (i.e.,
*...@_ and *%_)? I'm guessing not.
We only generate *...@_ and *%_ for subs when there is no signature; the
presence of placeholder parameters generates a signature, so you'd not
get them. Exception: methods, where by S12 we always add a *%_ unless
the method defines its own slurpy named parameter.
Hope this helps,
Jonathan
