On 8/24/05, Damian Conway <[EMAIL PROTECTED]> wrote: > Larry wrote: > > > Plus I still think it's a really bad idea to allow intermixing of > > positionals and named. We could allow named at the beginning or end > > but still keep a constraint that all positionals must occur together > > in one zone. > > If losing the magic from =>'d pairs isn't buying us named args wherever we > like, why are we contemplating it?
Well, that was one of the nice side-effects of the proposal, solving something that had been bugging me. But the main reason for this proposal was to demote Pair into a regular data type that wouldn't sneak into somebody's named argument when we weren't looking. In the Old Regime, I fear that I would never ever use Pair *except* for named arguments precisely because I need to keep far too much information in my head to use them safely. > > so we should put some thought into making it syntactically trivial, if > > not automatic like it is now. The whole point was to deautomatize it! However, here's an interesting solution: pairs are scanned for *syntactically* *on the top level* of a function call (allowing named() or however we spell it as a fallback when we want to be dynamic). However, :foo(bar) and foo => bar are equivalent again. foo $x, $y; # two positionals, regardless of what they contain foo $x, :y($y) # a positional and a named foo $x, y => $y # a positional and a named foo $x, (y => $y) # two positionals: $x and the pair y => $y foo $x, (:y($y)) # same In the fourth example, y => $y is no longer on the syntactic top level, so it is not interpreted as a named argument. > > > I hate to say it, but the named args should probably be marked > > with : instead of + in the signature. That's pretty cool. Can't say I like the secondary sigil: it's really not marking a property of the variable, but a property of the parameter list. That information should probably be kept inside the parameter list alone. Luke