develooper Front page | perl.perl5.porters | Postings from November 2017

Re: Revisiting smart match

Thread Previous | Thread Next
Leon Timmermans
November 24, 2017 12:28
Re: Revisiting smart match
Message ID:
On Wed, Nov 22, 2017 at 8:29 PM, Zefram <> 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.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About