Front page | perl.perl5.porters |
Postings from November 2017
Re: Revisiting smart match
From: Leon Timmermans
November 24, 2017 12:28
Re: Revisiting smart match
Message ID: CAHhgV8iADcvFc=2AwiERTat7Yc1nhHNRK5FLAuX_HAn1Memail@example.com
On Wed, Nov 22, 2017 at 8:29 PM, Zefram <firstname.lastname@example.org> wrote:
> Sawyer X wrote:
> >We haven't resolved smart match yet and I think it just might be time,
> >long enough before 5.28, to revisit this topic and reach a decision.
> I have implemented a simplification based on the consensus reached
> in recent mail threads. It's on branch zefram/dumb_match. It's the
> minimalistic version, specifically:
> * given() has no implicit enreferencement, only regular scalar context
> * when() has no implicit enreferencement, only regular scalar context
What do you mean exactly with implicit enreferencement? This is not a term
that comes from our documentation.
> * when() never implicitly smartmatches, only uses arg as truth value
This doesn't really make sense to me: why would anyone want to use this?
> * ~~ has no implicit enreferencement, only regular scalar context
> * ~~ has rhs overloading as the only matching mechanism
> We can sensibly apply this for 5.28, and I think we should. While not
> necessarily the final form in which we'll want the smartmatch features
> to be, this is clearly going to be quite close to the eventual form.
> It's a big step forward in the experiment.
> If we end up wanting any more complicated behaviour than this, it's
> probably better to add them onto this clean minimal setup than to have
> another attempt at cutting out only the bits we don't want. Of the
> various features being dropped, the only one that I found really
> conspicuous by its absence was the shorthand for smartmatching in
> "when". If we want to add such a shorthand back, it should be alongside
> the truth-value-argument arrangement, distinguished syntactically.
> I currently think the best spelling would be "when~($matcher)".
> (We'd also have the option of a parallel "if~($matcher)" syntax.)
Breaking code with the idea "maybe we will unbreak it, but not before
you've suffered the pain" sounds unnecessarily cruel.
> I didn't change the behaviour of "break" or loop control features.
> If FC wants to change that, that can happen fairly independently of what
> I've done. (FC should not wait for a counter-proposal from whichever
> ex-pumpking he was referring to.) I have no strong feelings about
> FC's proposal there. We shouldn't hold up simplifying the things I've
> addressed in order to wait for a resolution of loop control.
While the current behavior a bit is strange. I've never actually observed
issues with it. I guess I don't care much either.