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