Front page | perl.perl5.porters |
Postings from August 2022
Re: Pre-RFC: Optional Chaining
Thread Previous
|
Thread Next
From:
breno
Date:
August 16, 2022 03:19
Subject:
Re: Pre-RFC: Optional Chaining
Message ID:
CAHS-WQZQDSj-DP7ktfFN8wiT9PLobgVZDipf2zqu0bEBwLSCmw@mail.gmail.com
Hello members of the PSC!
Following up on the RFC process, I believe all feedback regarding the
Optional Chaining proposal has been properly addressed and, since nothing
new came up after what I think was a good interval, I would like the PSC to
accept this draft as exploratory.
If anyone would like to take another look at the current revised version,
you can find it at:
https://github.com/garu/RFCs/blob/garu/optional-chaining/rfcs/rfc0018.md
and the PR itself, with extra discussion, is here:
https://github.com/Perl/RFCs/pull/23
Thank you very much for your time and consideration.
Cheers!
garu
On Tue, Jul 26, 2022 at 7:15 AM Philippe Bruhat (BooK) <book@cpan.org>
wrote:
> On Sun, Jul 17, 2022 at 09:23:32PM +0200, Philippe Bruhat (BooK) wrote:
> > On Thu, Oct 28, 2021 at 02:39:15PM -0300, breno wrote:
> > >
> > > ## Rejected Ideas
> > >
> > > I am unaware whether this feature has already been proposed for Perl 5
> > > in the past.
> > >
> >
> > For completeness, I have (finally) looked in the archives for previous
> > proposals for the same feature. It used to be called "safe dereference"
> > or "safe arrow", and was discussed over a decade ago.
> >
> > ...
> >
> > It would be worth reading them, in case some of things discussed then
> > were not discussed this time around. And maybe a ten years old patch can
> > still be somewhat useful.
> >
>
> After sending this, I felt obligated to read the 180+ emails in the
> aforementioned threads.
>
> Here are some highlights from the conversations:
> * it started as &&-> and after much discussion and proposed alternatives
> about what the arrow
> could look like, Jesse Vincent (then pumpking) settled on ?->
> * a similar discussion about using a pragma happened, and reached
> a similar conclusion
> * the dereferencing overload operations were mentionned, and I _think_
> the consensus was that there's no need to add new overload methods
> related
> * what happens when the ?-> is part of an lvalue (and returns undef)?
> * one example of autovivification in perldoc -f exists was mentionned
> I expect it would "just work as expected" with ?->
> * David Caldwell sent two sets of patches, I'm sure there's interesting
> bits to look at in them, even if they don't apply anymore
> * the ?-> (deref if defined) vs ->? (return undef if not can) came up,
> this makes me thinks that once we have ?-> (topic of this RFC) and
> ->? (if someone writes the RFC for it), then surely we must have ?->?
> * the case of the hash key pointing to undef was discussed
> ( $h->{foo}?->method() where the foo key does not exist vs the foo key
> pointing to the value undef would behave the same)
> * all the examples and counter examples in those threads would make
> great test cases
> * several people complained about the keyboard gymnastics needed to
> type ?-> (but nobody compared that to the thing it replaces)
> * being able to use the question mark (`?`) inside operators seem related
> to the ?PAT? deprecation.
>
> Names I've seen used for it:
> * safe arrow
> * defined dereference
> * safe dereference
> * maybe dereference
> * safe-dereferencing arrow
> * short-circuiting dereference
> * conditional dereference
> * defreference
> * Twister⢠(because of the difficult key combination needed to type it)
> * undef-safe de-ref
> * defined and dereference
>
> My favorite quote from those threads, from Aristotle Pagaltzis, which I
> think applies remarkably to today's post-facts trends:
>
> > How can an opinion not founded in fact be changed by any change to
> > the factual situation?
>
> --
> Philippe Bruhat (BooK)
>
> Friendship is just brotherhood with a choice of brothers.
> (Moral from Groo #9
> (Image))
>
Thread Previous
|
Thread Next