Сравнение систем типов PHP7 и Hack

[@dim_s]

Мне больше понравился подход PHP7, он более практичен. Например взять тот же float, почему нельзя передавать int? Практически все строго-типизированные языки, которые я знаю, позволяют это делать, потому что так удобнее.

[@BaRoN]

Главное — чтобы в таком случае генерировался Warning про потерю дробной части числа.

[@nikita2206]

Там речь про int -> float, это конверсия без потери (в этом и суть widening-а), а float -> int не разрешен

[@k12th]

function myLog(string $message): string

Неконсистентно как-то опять, почему не

function myLog($message: string): string // тип всегда через двоеточие после объявления

или

function string myLog(string $message) // тип всегда перед объявлением через пробел

[@neolink]

потому что
function myLog(array $message)
уже давно работает

function string myLog(string $message)
это C какой-то, ну и синтаксический анализ в php традиционно не контекстно зависимый

в целом: string норм, вопрос только в ":"

офф ответ в самом rfc: wiki.php.net/rfc/return_types#position_of_type_declaration

[@k12th]

Ясно, спасибо!

[@Fesor]

не контекстно зависимый

Уже контекстно зависимый, правда опять же это было реализовано уже после принятия этого RFC. А выбор был сделан в пользу более читабельного варианта:

public static static foo() {}
// vs
public static foo() : static {}

А с аргументами да, жалко что нужно сохранять обратную совместимость.

p.s. опоздал…

[@beono]

function myLog($message: string): string 

Противоречит старым правилам записи функций и усложняет перевод старого кода.

function string myLog(string $message)

Получилась Java :) Тут на вкус и цвет. Немного ухудшает читабельность и поиск нужной функции в коде.

[@k12th]

Спасибо за объяснение. Я на PHP давно не пишу, отсюда дурацкие вопросы.

[@theRavel]

Я как-то не обращал на это внимание до статьи, а теперь почитал:

The strict_types directive only affects the specific file it is used in, and does not affect either other files which include the file, nor other files that are included by the file.

Привет такая же фигня как «use strict» в каждом файле, оох.

[@pandas]

Grace period. Всё верно. В следующих итерациях типизация вероятно будет строгая по-умолчанию, без обратной (и по всей видимости прямой, при версиях <=5) совместимости. А может быть так и останется, как знать.

[@iGusev]

Динамическая типизация — это не недосмотр языка, а одна из его концепций.

[@pandas]

Спокойно. Динамическая типизация это прекрасно, это значит что можно делать приведение типов в другие формы. А речь идёт о создании сильной и строгой типизации (Strong typing) в PHP. Это более правильная модель работы с той же памятью, и более корректным приведением типов, например.

[@nikita2206]

Скорее всего так и останется как есть. Оппозиция была очень сильная против строгой типизации даже в том варианте, в котором ее получилось протолкнуть, по-умолчанию такого точно не будет в пхп.

[@zviryatko]

А фигурные скобки в этом случае не помогут?

<?php
declare(strict_types=1) {
  require "file.php";
}

[@Fesor]

1) нет никаких фигурных скобок. Обсуждалось в RFC
2) strict_types действует только на тот файл, в котором оно объявлено и не дальше. То есть на инклуды не распространяется.

На самом деле можно просто жахнуть правило в PHP-cs-fixer например.

[@beono]

Тоже самое с неймспейсами в php и это логичное поведение.
В данном случае можно просто добавить объявление режима в шаблон создания нового класса в IDE