in reply to
Re: Perl5 Language Extension: Definedness-Triggered Shortcut Operators
in thread RFC: Perl5 Language Extension: Definedness-Triggered Shortcut Operators
Why don't you start by digging into the p5p archives, and refute the reasons why of all the proposals, only // survived? And while you are at it, explain why we need a :|| identical to //.
Twelve years worth of p5p is a lot of ground to dig through, so I have only just begun. Here is a summary of what I have found so far.
- There has indeed been debate about quite a number of operators looking at definedness.
- Objections mostly address syntactical issues. Opinions stating that it was bad to have such operators at all seem to be very rare.
- The "safe arrow" operator in particular has got a lot of support, though its symbol is not quite settled yet. One of its benefits I did not mention in my first post is that it can disable auto-vivification.
- The double-slash symbol seems to have made it because of high demand for expressions with default values and it being the syntax proposed by Larry Wall for Perl 6.
- Low-precedence defined-or was initially called "err", but its naming was later challenged. Larry himself did not like "dor" either, and he pointed out that "orelse", which is what "err" evolved into in Perl 6, has different semantics now that would not easily fit into Perl 5.
- My primary concerns, i.e. the usefulness of short-cutting expression evaluation and the intent to provide more general solutions than an isolated exotic operator, don't seem to have played a major role in the discussion lately.
- Colons indeed seem to be some sort of holy ground nobody dares to touch.
- Points made in favour of a new syntax are often among these: (a) Has the new syntax been illegal before, so that old code is not likely to get hurt? (b) Do similar things look similar and dissimilar things look different? (c) Is the new syntax easy to use and remember? (d) Does it fit in the general look-and-feel of the language? (e) Are names free of different meanings or possible misunderstandings? (f) Is the impact on the existing language parser(s) limited?
As to the coexistence of different symbols, I have already tried to convey that one of them should be preferred but the other one cannot suddenly be made illegal. This has precedents, like tr versus y, or version objects versus v-strings.