I shall address your concern here in roughly reverse order:
* Tom Christiansen [2012-02-25 23:35]:
> Since we won't let either of those happen, I figure that either
> —— all #1 .. #9 of my numbered points above are completely safe and
> proper, preferably always but minimally along with the #0
> —— or else they need to be made so before we dare release v5.16.
5.16 *must* be released whatever the state of this issue. To not do so
is to fall into the thinking and behavioural pattern that stifled the
release of 5.10 by several years. Perl 5 switched to a timeboxed release
cycle because “this one more thing has to be polished before we can ship
it” meant it never shipped at all.
It has been a rousing success.
The key to said success is that no feature, no matter how exceptional it
may appear, is special. If it isn’t ready in time, it can wait –
it will not have to wait long, because when time arrives for it to ship
it will not have to wait for any *other* feature in turn, because none
No matter how important any one particular issue may appear: for the new
regime to work, none must be considered more important than the release
schedule. The trains must run on time.
> Why? Simple: remove those 9 simple ways to approach implicit Unicode
> processing in Perl, and you so gut Perl's Unicode dwimmer that nobody
> save the very most diligent and élite [sic] of Perl gurus will ever dare
> use Perl with Unicode. That would be tragic, maybe disastrous even.
I am rather more sanguine about that. Let me help you relax by giving
you the reason – two of them, in fact. Firstly:
> We should not have to endure five more tedious years of people getting
> tonguelashed and flamenagged into writing horribly complicated code
> all because something deep down in Perl's dwimmer is flawed.
> I say five years, not one year, because of how long it takes to get
> vendors to get themselves updated. If this is a legit issue, and we
> push it off till 2013's v5.18, then it will be a further 2–4 years
> past that until people can have reasonable Unicode processing in their
> vendor Perl. That puts us into the 2015–2017 (!) time frame, and...
> that's just not acceptable, eh?
You ignore here that by this calculation, the question is *only* whether
the 4-year trickle-down process starts now or next year. Neither is
there any (known) non-linear process at work that would make a delivery
now trickle down much quicker than a delivery next year – the 4-year
process is identical either way.
So your worst-case scenario has to be compared against a parallel better
case of 4 years. It is not “ship it this time and get it now or wait
5 years”: it is “ship it this time and get it in 4 years or leave it to
be shipped next year and get it in 5, counting from now”.
Accounting for constant factors, the difference between the scenarios is
just 1 year, no matter what else the full process involves.
Then the gravity of the decision to consider is the gravity of one year.
> By that time, one or both of two things will have happened. Either
> untold zillions of lines of code will have been written that either
> conform to this ridiculous amount of monkeywork, entrenching a bad
> pattern forever, or else untold zillions of line of code will have
> been written that ignore it and are themselves open to the kind of
> spooky catastrophic failure that people allude to, thereby rendering
> all Perl a security hole of Chicken Little proportion.
This ignores a third option à la “use Try::Tiny until we have sane
exceptions in core”.
We have the CPAN.
It is no alternative to fixing the core language – but *is* an
alternative to copy-pasting workaround patterns all over code. And it
can trickle out *much* faster than an update to the core ever will be
Since according to your premises we are looking at 4 years in the
best-worst case, no matter how this plays out, then if the situation
is as grave and perilous as it appears to you, maybe the thing to do is
start to think *now* about how to create an interim DWIM solution that
can live on CPAN.
And incidentally, maybe it is also time to consider whether and where
the points that utf8::all implicitly argues (by virtue of its existence)
mean the design of the core language should be moving toward regarding
So with all that said, let us take a breath and focus on strategy, and
leave the release schedule to care for itself.
Aristotle Pagaltzis // <http://plasmasturm.org/>