From 8a02180315edaaa9753e7716403710f474fcac15 Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Mon, 25 Nov 2024 21:46:29 +0000 Subject: [PATCH 1/3] Suggest that the feature flags should be called 'any' and 'all' to match the operators --- ppcs/ppc0027-any-and-all.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/ppcs/ppc0027-any-and-all.md b/ppcs/ppc0027-any-and-all.md index 177954a..1cf1baf 100644 --- a/ppcs/ppc0027-any-and-all.md +++ b/ppcs/ppc0027-any-and-all.md @@ -19,9 +19,11 @@ Most code of any appreciable size tends to make use of at least the `any` or `al ## Specification -New named features that, when enabled, activate syntax analogous to the existing `grep` operator, named `any` and `all`: +New named features that, when enabled, activate new operators analogous to the existing `grep` operator. The features, and the operators, are named `any` and `all`: ```perl +use feature qw( any all ); + any { BLOCK } LIST all { BLOCK } LIST @@ -50,7 +52,7 @@ Some::Class->new( ## Backwards Compatibility -As these new operators are guarded by named features, there are no immediate concerns with backward compatiblity in the short-term. +As each new operator is guarded by a named feature, there are no immediate concerns with backward compatiblity in the short-term. In the longer term, if these named features become part of a versioned feature bundle that is enabled by a corresponding `use VERSION` declaration there may be concerns that the names collide with functions provided by `List::Util` or similar modules. As the intention of these operators is to provide the same behaviour, this is not considered a major problem. Differences due to caller scope as outlined above may be surprising to a small number of users. @@ -60,7 +62,7 @@ In the longer term, if these named features become part of a versioned feature b ```perl use v5.40; -use feature 'any'; +use feature qw( any ); if( any { $_ > 10 } 5, 10, 15, 20 ) { say "A number above 10" } ``` @@ -114,10 +116,6 @@ In any case, as junctions behave like values, they do not require special syntax ## Open Issues -* There could be anything up to five new operators added by this idea. Do they all get their own named feature flags? Do they all live under one flag? - -* Should the flag be called `any`? That might be confusing as compared to the `:any` import tag which would request all features. - ## Copyright Copyright (C) 2024, Paul Evans. From 34d7098d8218c916de01e2177a2c505b1082d4ad Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Mon, 25 Nov 2024 21:49:40 +0000 Subject: [PATCH 2/3] Add a Future Scope idea to suggest that $_ could be a readonly copy, not an alias --- ppcs/ppc0027-any-and-all.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/ppcs/ppc0027-any-and-all.md b/ppcs/ppc0027-any-and-all.md index 1cf1baf..ddf761d 100644 --- a/ppcs/ppc0027-any-and-all.md +++ b/ppcs/ppc0027-any-and-all.md @@ -89,6 +89,12 @@ These lexicals are useful when nesting multiple calls to list-processing operato If this feature is to be considered, it will require careful thought on how it might interact with the so-far-unspecified idea of accepting `any EXPR, LIST` as `grep` currently does. I would recommend not allowing that variant, to allow for easier implementation of these named lexicals in future as they provide advantages that outweigh the minor inconvenience of having to wrap the expression in brace characters. +### Read-only Copy Rather Than Alias + +A little-used behaviour of `grep` and `map` is that the `$_` variable does not merely store a copy of each original list element but actually aliases it. This is almost never used intentionally and can often lead to accidentally modifying the original list values, leading to subtle data corruption bugs. + +A possible future idea is a named feature that alters this behaviour of `grep` and `map`, as well as these new operators, into using read-only copies of the original data, rather than aliases. + ### Other Operators * The other two variant behaviours of `none` and `notall`. These simply invert the sense of the filter block. From 5baf2c9c42f061d94d0b3bc39f217b84103706eb Mon Sep 17 00:00:00 2001 From: "Paul \"LeoNerd\" Evans" Date: Wed, 4 Dec 2024 18:15:06 +0000 Subject: [PATCH 3/3] Expand on wording of Rejected Ideas section about deferred expression syntax --- ppcs/ppc0027-any-and-all.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ppcs/ppc0027-any-and-all.md b/ppcs/ppc0027-any-and-all.md index ddf761d..035152a 100644 --- a/ppcs/ppc0027-any-and-all.md +++ b/ppcs/ppc0027-any-and-all.md @@ -103,9 +103,9 @@ A possible future idea is a named feature that alters this behaviour of `grep` a ## Rejected Ideas -### Block-less syntax +### Deferred Expression Syntax -Supporting syntax analogous to the "deferred-expression" form of `grep EXPR, LIST`. +Supporting syntax analogous to the "deferred-expression" form of `grep EXPR, LIST` in the first iteration is likely to get in the way of a possible future idea to add named lexical arguments to the predicate test block (see above). Therefore at this time no attempt is made to support these, so as to leave an easy space in the implementation to allow other behaviours in future. ### Keywords as Junctions