Damian Conway wrote:
> I intend to extend the parameter lists RFC to cover optional
> (non-tailing) arguments. Personally, I would like to see the
> indirect object syntax removed in all contexts, inclusing
> this one, and filehandles simply passed as a first argument.
Well, "indirect object syntax", maybe; but then, eh...
comma-less-ness can be very nice in many situations.
I think this should be allowable whenever it's unambiguous to
the compiler, based on the prototype. IOW, given
sub foo($$$&);
should not the following be legal?
foo $x ( $y, $z ) { ... }
--
John Porter
We're building the house of the future together.
- Re: RFC 168 (v1) Built-in functions should be functi... Damian Conway
- Re: RFC 168 (v1) Built-in functions should be fu... Tom Christiansen
- Re: RFC 168 (v1) Built-in functions should b... John Porter
- Re: RFC 168 (v1) Built-in functions should b... Piers Cawley
- Re: RFC 168 (v1) Built-in functions shou... Tom Christiansen
- Re: RFC 168 (v1) Built-in functions... Piers Cawley
- Re: RFC 168 (v1) Built-in functions... Damian Conway
- Re: RFC 168 (v1) Built-in functions should be fu... Nathan Wiger
- Re: RFC 168 (v1) Built-in functions should b... Tom Christiansen
- Re: RFC 168 (v1) Built-in functions shou... Nathan Wiger
- Re: RFC 168 (v1) Built-in functions should be fu... John Porter
- Re: RFC 168 (v1) Built-in functions should be functions Damian Conway
- RE: RFC 168 (v1) Built-in functions should be functions Fisher Mark
