p
ну самое время начинать её писать
пусть разрабы пишут лол
Size: a a a
2021 February 19
p
это их работа
ID
GAT'ы ведь скоро, кто-нибудь видел крейты с реализацией новой std? а то ничего кроме generic_std не нашел
Кто такие гаты?
EG
Кроме того, у Go есть compatibility promise, который мешает им переписать хотя бы std, чтобы она перестала бросаться пустыми интерфейсами во все стороны
А⚙
И зачем это вообще надо? Как эти телодвижения улучшают корректность программы с точки зрения системы типов?
Вот например(это псевдокод) у меня есть такая программа:
Вот эти все "я хочу" вполне выводятся в компил-тайме без взяких именованных интерфейсов, тайпклассов и прочего обслуживания компилятора.
Вот например(это псевдокод) у меня есть такая программа:
var foo = {a: 100, b: 200.0}; // я хочу чтобы он мне вывел тут что foo типы {a: int, b: float}
function bar(param: {a: int}) {
}
// я хочу, чтобы тут он понял, что я передаю объект, соответствующий запрошенному интерфейсу.
bar(foo)
Вот эти все "я хочу" вполне выводятся в компил-тайме без взяких именованных интерфейсов, тайпклассов и прочего обслуживания компилятора.
Это совершенно не предотвращает ситуаций, когда ты передал в функцию не то, а код компилируется, потому что значение удовлетворило интерфейс случайно
Z
Кто такие гаты?
Z
это их работа
её скорее всего до 2.0 менять не будут
А⚙
И зачем это вообще надо? Как эти телодвижения улучшают корректность программы с точки зрения системы типов?
Вот например(это псевдокод) у меня есть такая программа:
Вот эти все "я хочу" вполне выводятся в компил-тайме без взяких именованных интерфейсов, тайпклассов и прочего обслуживания компилятора.
Вот например(это псевдокод) у меня есть такая программа:
var foo = {a: 100, b: 200.0}; // я хочу чтобы он мне вывел тут что foo типы {a: int, b: float}
function bar(param: {a: int}) {
}
// я хочу, чтобы тут он понял, что я передаю объект, соответствующий запрошенному интерфейсу.
bar(foo)
Вот эти все "я хочу" вполне выводятся в компил-тайме без взяких именованных интерфейсов, тайпклассов и прочего обслуживания компилятора.
Ну и тайпклассы шире интерфейсов. Как ты предлагаешь компилятору выводить, скажем, FromStr? Или Send?
ΑZ
И зачем это вообще надо? Как эти телодвижения улучшают корректность программы с точки зрения системы типов?
Вот например(это псевдокод) у меня есть такая программа:
Вот эти все "я хочу" вполне выводятся в компил-тайме без взяких именованных интерфейсов, тайпклассов и прочего обслуживания компилятора.
Вот например(это псевдокод) у меня есть такая программа:
var foo = {a: 100, b: 200.0}; // я хочу чтобы он мне вывел тут что foo типы {a: int, b: float}
function bar(param: {a: int}) {
}
// я хочу, чтобы тут он понял, что я передаю объект, соответствующий запрошенному интерфейсу.
bar(foo)
Вот эти все "я хочу" вполне выводятся в компил-тайме без взяких именованных интерфейсов, тайпклассов и прочего обслуживания компилятора.
bar : HasA param => param -> ()
record Foo = Foo { a : Int, b: Int} deriving HasA
let foo = Foo 100 200
in bar foo
ну и?EG
Ну то есть гошные дженерики как-то решает ту проблему, что го вообще никак невозможно пользоваться, но они всё ещё говно
IL
Это совершенно не предотвращает ситуаций, когда ты передал в функцию не то, а код компилируется, потому что значение удовлетворило интерфейс случайно
Если значение удовлитворило запрошенный интерфейс, значит значение может быть обработано данной функцией, либо функция плохо сделана, расширяй её интерфейс.
EG
Если значение удовлитворило запрошенный интерфейс, значит значение может быть обработано данной функцией, либо функция плохо сделана, расширяй её интерфейс.
Семантика
EG
Представим себе, что функция принимает интерфейс
И мы случайно передали в функцию не штуковину, которая присылает клиенту отчёт, а штуковину, которая посылает клиента нахуй
send: async fn()И мы случайно передали в функцию не штуковину, которая присылает клиенту отчёт, а штуковину, которая посылает клиента нахуй
IL
Ну и тайпклассы шире интерфейсов. Как ты предлагаешь компилятору выводить, скажем, FromStr? Или Send?
function foo(something_to_sting: {to_string: (x) -> String})условно говоря так.
ΑZ
И зачем это вообще надо? Как эти телодвижения улучшают корректность программы с точки зрения системы типов?
Вот например(это псевдокод) у меня есть такая программа:
Вот эти все "я хочу" вполне выводятся в компил-тайме без взяких именованных интерфейсов, тайпклассов и прочего обслуживания компилятора.
Вот например(это псевдокод) у меня есть такая программа:
var foo = {a: 100, b: 200.0}; // я хочу чтобы он мне вывел тут что foo типы {a: int, b: float}
function bar(param: {a: int}) {
}
// я хочу, чтобы тут он понял, что я передаю объект, соответствующий запрошенному интерфейсу.
bar(foo)
Вот эти все "я хочу" вполне выводятся в компил-тайме без взяких именованных интерфейсов, тайпклассов и прочего обслуживания компилятора.
не поверишь, это не обслуживание компилятора. Я хочу как юзер видеть чо от меня функция bar ожидает
ΑZ
а не чтобы она падала "ой мне передали говно"
EG
С номинативными интерфейсами у тебя нет риска пересечения названий функций у разных вещей
ID
её скорее всего до 2.0 менять не будут
Когда раст 2.0 выйдет == когда рак на горе свиснет
EG
С структурными интерфейсами, тебе всегда нужно думать «а точно ли эта функция делает ровно то, что мне нужно»
А⚙
Если значение удовлитворило запрошенный интерфейс, значит значение может быть обработано данной функцией, либо функция плохо сделана, расширяй её интерфейс.
Даже если значение из одной либы, а функция — из другой?