Надо как-то поспрашивать про это дело. А то мне как-то не нравится эта инициатива, несмотря на её разумность. Если это так важно, пусть бы сделали dfoy::sense и предложили бы её поюзать. Ну и присоединяюсь как минимум к кодированию типа строки (байты/юникод) в каком-то бите.

этот бит уже есть: UTF8_FLAG
просто нужно поведение поменять немного

просто 10 лет назад пара идиотов из мира питоновского duck-typing неправильно поняли назначение UTF8_FLAG и покернули всю разработку не туда

Например. Просто, возможно, именно этот флаг не рискнут менять как раз из-за огромного корпуса софта. Так что возможно, имеет смысл ввести какой-нибудь unicode (use unicode) и отдельный флаг (если там есть резерв).
И ещё, конечно, динамическая типизация раньше считалась хорошей вещью, но сейчас как-то совсем далеко от мэйнстрима - то есть хорошо бы, что бы не-unicode фэйлился с исключением при попытке преобразования в unicode...

Блин, да ради возможности сломать обратную совместимость и делается отельная версия
убрать indirect, убрать ' вмсто ::, починить utf

Мне кажется, это не питонщики виноваты, а наоборот, олдовые сисадмины из latin-1 мира. Типа, у нас всё работает со старым софтом, а вы - как хотите.

нет. погуглите The Unicode Bug
Там имнно, что корректное поведение от 5.8 начали "улучшать", потому что видите-ли строка с utf8_on и строка с utf8_off по поведению вглядят одинаково, значит и работать должны одинаково

Я пока про это не нашёл. Пока объявление звучит так, что просто бойлерплейта не будет (я не очень понимаю, как это сделать без замены бойлерплейта например одной прагмой, типа "use v7;" так, что бы старый набор кода тоже работал). Они же не собираются старый набор кода (из Core и CPAN) портировать под 7?

Собираются, по всей видимости.

Вопрос в сроках.

А можно простым языком сказать нафига козе баян и какая проблема этим решается что вдруг перл 7 рванет в космос?

а куда? и почему Питон? в перле утф наиболее разумно сделан, относительно конкурентов

Я когда-то описывал всё. Был нехилый длиннопост.

Помню, в своё время PHP реанимировали с версией 7. Ну, правда, ненадолго реанимировали.
Но там ключевой вещью были отнюдь не свистоперделки, людям, которые платят, обычно в общем-то пофигу, насколько язык соответствует представлениям погромистов о прекрасном. Там главное "новшество" было - увеличение производительности интерпретатора реально в разы. Что означало больше лемингов, обработанных рекламой, больше проданного говна в инет-гамазинах и т.д.

Чтоооо?

In split.

Starting in Perl 5.28.0, the split function with a pattern specified as a string containing a single space handles whitespace characters consistently within the scope of of unicode_strings . Prior to that, or outside its scope, characters that are whitespace according to Unicode rules but not according to ASCII rules were treated as field contents rather than field separators when they appear in byte-encoded strings.

Вот как раз из-за наслоения подобных умолчаний шатается экосистема перла. Впрочем, возможно тут описана здравая мысль, просто документирована плохо. Но вообще, если ты хочешь юникодных пробелов, цифр и т.д. - разумно было бы явно писать это в паттернах...

В случае с Perl 7 - это больше похоже на предсмертную горячку умирающего от малярии, честное слово

Текущее состояние работы флага UTF8 и функций - это (на мой взгляд) одна из самых больших ошибок в дизайне языка
когда только был внедрён флаг поведение было более корректным, чем сейчас, но позднее кто-то заметил, что
строка с флагом, разбтая посимвольно и дающая массив 1..255 не равна строке без флага, которая при разбитии посимвольно (побайтово) даёт массив 1..255
это не удивительно, т.к внутренний байтовый массив абсолютно разный
лично я считаю, что сделовало сделать одну простую вещь: сказать, что строка с флагом никогда не может равняться строке без флага
благо инструментарий для проверки на флаг уже был.
но было принято другое решение. поведение было названо "The Unicode Bug" и были внесены изменения, которые приводили к равенству таких строк.
после этого стали создаваться сотни реквестов в RT о том, что модуль подвержен "the unicode bug" (мои были в их числе)
длительная переписка с автором этих тикетов не привела ни к чему. мне не удалось убедить его в том, что такое поведение это нонсенс:

$ perl -MDevel::Peek -E '$a = "\N{U+fd}"; $b = "\xfd"; Dump $a; Dump $b; say $a eq $b'
SV = PV(0x7fd2f3806070) at 0x7fd2f382dd48
  REFCNT = 1
  FLAGS = (POK,IsCOW,pPOK,UTF8)
  PV = 0x7fd2f3401b40 "\303\275"\0 [UTF8 "\x{fd}"]
  CUR = 2
  LEN = 10
  COW_REFCNT = 1
SV = PV(0x7fd2f3806120) at 0x7fd2f382dcd0
  REFCNT = 1
  FLAGS = (POK,IsCOW,pPOK)
  PV = 0x7fd2f3401770 "\375"\0
  CUR = 1
  LEN = 10
  COW_REFCNT = 1
1

Поэтому текущая ситуация такая:
- поведение строк в core приведено к duck-typing.
- на флаг UTF8 сказано не обращать внимания (т.е. если вам сказали записать в сокет такую SV'шку,   FLAGS = (POK,IsCOW,pPOK,UTF8) PV = 0x7fd2f3401b40 "\303\275"\0 [UTF8 "\x{fd}", вы должны записать один байт 0xFD)
это невероятно печально, но это факт. можно пытаться отрицать, можно принять, но в любом случае нужно знать как оно есть.

есть 2 категории модулей:
1. old-way модули. которые отрицают существование "байтовых строк с флагом". поэтому при наличии флага строка либо энкодится ("\x{fd}" -> "\303\275"), либо бросается exception
2. new-way модули. которые просто разбирают строку по токенам, и если вдруг им нужны байты, а пришёл "символ" с кодом больше 255, бросается исклчение.

о как

Таким образом можн выяснить, что модуль Digest::MD5 является new-way модулем, т.к. спокойно энкодит строку с флагом

perl -MDigest::MD5=md5_hex -MDevel::Peek -E '$a = "\N{U+fd}"; $b = "\xfd"; Dump $a; Dump $b; say md5_hex($a); say md5_hex($b)'
SV = PV(0x7f8404001e70) at 0x7f8402811610
  REFCNT = 1
  FLAGS = (POK,IsCOW,pPOK,UTF8)
  PV = 0x7f8402509720 "\303\275"\0 [UTF8 "\x{fd}"]
  CUR = 2
  LEN = 10
  COW_REFCNT = 1
SV = PV(0x7f8404001f30) at 0x7f840280d700
  REFCNT = 1
  FLAGS = (POK,IsCOW,pPOK)
  PV = 0x7f84025016b0 "\375"\0
  CUR = 1
  LEN = 10
  COW_REFCNT = 1
da564f38413a243e30e8c8c07fccc5d8
da564f38413a243e30e8c8c07fccc5d8

Самое обидное, что когда меня студенты или коллеги спрашивают про различные вещи в языке, я могу объяснить "почему так" фактически про всё.
Кроме "The Unicode Bug". Про него приходится отвечать что-то в духе: "ну, так сделали..."