My problem with it being in the signature is still that it doesn't say which part of the contract it applies to; it appears to be claiming it's part of dispatch, when it's not.
On Fri, Oct 5, 2018 at 12:01 PM Larry Wall <la...@wall.org> wrote: > On Thu, Oct 04, 2018 at 09:35:08PM +0200, JJ Merelo wrote: > : El jue., 4 oct. 2018 21:21, Brandon Allbery <allber...@gmail.com> > escribió: > : > : > I don't think we've reached the point of such conventions yet. And > there's > : > some history here, in --> not having done anything in the early days > except > : > possibly slow things down, and between --> and 'returns' (which is now > : > deprecated). > : > > : > : Not yet. Maybe never... > > --> generalizes to pointy blocks and such. 'returns' doesn't. > > --> allows return of explicit literal Nil and True and 42. 'returns' > doesn't. > > --> makes the return an official part of the routine's contract. > 'returns' doesn't. > > For various purposes it would be nice to know we have the entire in/out > contract > before we start processing all the oh-by-the-way traits that can turn the > contract > into a time-traveling brain pretzel. For instance, what if one of the > phaser traits > needs to know will be returned, and the 'returns' comes after that? > Putting in error > messages that say "Too late for returns trait" is a design smell... > > So never say never. :) > > Larry > -- brandon s allbery kf8nh allber...@gmail.com