Для хипстеров.

Проще и красивее, наверное, скриншоты из vscode выдергивать.

надо конечно лигатуры и кнопку копировать в буфер

Заведи ишшуй!

Завёл целых две.

Проще и красивее, наверное, скриншоты из vscode выдергивать.

В этом случае качество картинки сильно зависит от разрешения монитора.

Да, пожалуй.

а файлом?

У тебя глаза не болят от такого мелкого шрифта?

У тебя глаза не болят от такого мелкого шрифта?

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

Там новый райдер вышел, F# .Net Core не починили?

https://github.com/fsharp/fslang-suggestions/issues/612

Спасибо всем, кто лайкнул. Сайм аппрувнул. :3

/

Спасибо всем, кто лайкнул. Сайм аппрувнул. :3

Потому что мы сила! :)

That makes this the fastest approved suggestion from the community ever I think :)

А моё прошлое предложение он апрувнул за несколько минут ? (но оно было не настолько важным, я там просто ворнинги предлагал поменять)

Нян. https://github.com/Microsoft/visualfsharp/pull/3582#issuecomment-332628580

Так что, их (трейты/тайпклассы) всё-таки скорее введут, чем не введут?

Так что, их (трейты/тайпклассы) всё-таки скорее введут, чем не введут?

Я бы сказал, что это настоящие трейты. Просто починили SRTP.

Но да, эта фича — кандидат на включение в F#4.2

Я бы сказал, что это настоящие трейты. Просто починили SRTP.

Ок, а что с добавлением этих трейтов можно будет сделать (чего раньше нельзя было)? Ну и чем они будут хуже настоящих трейтов/тайпклассов?

Но да, эта фича — кандидат на включение в F#4.2

Есть ли какие-то хотя бы приблизительные сроки релиза F# 4.2?

Есть ли какие-то хотя бы приблизительные сроки релиза F# 4.2?

Не, пока нету. Я думаю, эта работа будет вестить после того, как разберутся с тулингом для .NET Core в VS2017.

А тайпклассы в C# когда завезти собираются?

А, ну тогда, наверное, не раньше весны.

А тайпклассы в C# когда завезти собираются?

C#9? В восьмой версии, кажется, уже не будет.

C#9? В восьмой версии, кажется, уже не будет.

Уже 8 утвердили?

Уже 8 утвердили?

Я не слежу, спроси в C# чате.

Ок, а что с добавлением этих трейтов можно будет сделать (чего раньше нельзя было)? Ну и чем они будут хуже настоящих трейтов/тайпклассов?

Хуже синтаксисом; нужно расписывать все требуемые методы.

Настоящие трейты все-таки удобны тем, что они выглядят как интерфейсы: набором операций, объединенных один именем.

А тут будут типа абстрактного класса?

Хуже синтаксисом; нужно расписывать все требуемые методы.

Это решается отдельно, были же пропозалы на это.

Это решается отдельно, были же пропозалы на это.

А я не нашел, кстати.

Был RFC на починку синтаксиса SRTP.

А вот про алиасы для констрейнтов — не нашел.

А тут будут типа абстрактного класса?

Будет как везде в SRTP. В констрейнтах придется отдельные требуемые методы прописывать.

А extend-операторы можно делать или нет?

А то на операторах-то бы всё получилось само.

А extend-операторы можно делать или нет?

А вон я пример скинул же.

А, т.е. просто будет завязка на имя метода, а не реализация экземпляра тайпкласса?

type System.Int32 with static member (++)(a: int, b: int) = a 1 ++ 2

А, т.е. просто будет завязка на имя метода, а не реализация экземпляра тайпкласса?

Да.

А, ну и збс.

Я не слежу, спроси в C# чате.

А надо следить ?

Значит, можно все методы тайпклассов заменить операторами, и SRTP будет сам выводить, какие операторы нужны. Да и читать такой код намного веселее, правда же? ?

Ладно. А по сравнением с текущими возможностями что добавится? А то, признаться, я не то что бы хорошенько опробовал все возможности SRTP.

Ладно. А по сравнением с текущими возможностями что добавится? А то, признаться, я не то что бы хорошенько опробовал все возможности SRTP.

Хм. Ты сможешь добавлять чужим типам нужные методы и писать относительного этого обобщенные функции.

Ну можно разве что type augmentation сделать

Сейчас

значит ли это, что List.map, Seq.map, Option.map больше не нужны и везде можно будет делать просто map?

А, я понял. Сейчас, видимо, эти добавленные методы не будут видны для обобщения, так?

@gsomix ты вроде AvaloniaUI рекламировал, как там дела обстоят с производительностью? просто когда я тыкал демо с контролами, оно дико тормозило...

значит ли это, что List.map, Seq.map, Option.map больше не нужны и везде можно будет делать просто map?

Это и сейчас можно сделать, если захотеть.

значит ли это, что List.map, Seq.map, Option.map больше не нужны и везде можно будет делать просто map?

Стандартная библиотека не поменяется. :)

А, я понял. Сейчас, видимо, эти добавленные методы не будут видны для обобщения, так?

Да, верно.

@gsomix ты вроде AvaloniaUI рекламировал, как там дела обстоят с производительностью? просто когда я тыкал демо с контролами, оно дико тормозило...

Лучше спросить у @nikita_tsukanov в @csharpchat.

Это и сейчас можно сделать, если захотеть.

FSharpPlus, например?

FSharpPlus, например?

Без него можно.

Просто пишешь функцию map<^T>, которая вызывает T.map.

Лучше спросить у @nikita_tsukanov в @csharpchat.

что-то много разных чатов стало)))

что-то много разных чатов стало)))

Ну, он главный по Авалонии в телеге. :)

Про F# только один чат. Остальные про другое (в основном про C#).

Просто пишешь функцию map<^T>, которая вызывает T.map.

Для модулей SRTP не работает же.

Для модулей SRTP не работает же.

Блин!

Да, ты прав. Ну, значит, пока не судьба.

Ну, он главный по Авалонии в телеге. :)

а можешь username еще подсказать?)

Просто пишешь функцию map<^T>, которая вызывает T.map.

Хм, до такого не додумывался. Хотя не то что бы много об этом думал.) Меня варианты <module name>.<function name> в каком-то смысле даже нравятся, т.к. сразу ясно, где какой тип. Особенно, если в конвейере есть переходы от одного к другому.

а можешь username еще подсказать?)

@nikita_tsukanov

Хм, до такого не додумывался. Хотя не то что бы много об этом думал.) Меня варианты <module name>.<function name> в каком-то смысле даже нравятся, т.к. сразу ясно, где какой тип. Особенно, если в конвейере есть переходы от одного к другому.

@gsomix говорит, что так не будет работать :(

Да, ты прав. Ну, значит, пока не судьба.

Есть FSharp.Core.Fluent с нужными методами расширений для List, Array и так далее.

@nikita_tsukanov

спс

В рамках этой библиотеки можно будет дописать обобщенные реализации.

Есть FSharp.Core.Fluent с нужными методами расширений для List, Array и так далее.

Ты сам знаешь, какая у него проблема!

Ты сам знаешь, какая у него проблема!

А я починю.

?

Сегодня пойти и починю. Теперь эта библиотека кажется мне очень важной. :)

@gsomix говорит, что так не будет работать :(

Ну и ладно. Единственное, что пока реально бывало нужным, это обобщённый >>= оператор. Когда в коде использовал как Option, так и Choice и не хотелось писать длинные |> Option.bind ... и |> Choice.bind ...

Ну и ладно. Единственное, что пока реально бывало нужным, это обобщённый >>= оператор. Когда в коде использовал как Option, так и Choice и не хотелось писать длинные |> Option.bind ... и |> Choice.bind ...

@gsomix говорит, что он всё починит и будет збс (ну, если тот пропозал вмержат)

Ну и ладно. Единственное, что пока реально бывало нужным, это обобщённый >>= оператор. Когда в коде использовал как Option, так и Choice и не хотелось писать длинные |> Option.bind ... и |> Choice.bind ...

С приседаниями его и сейчас можно реализовать для закрытого набора типов.

Ну я просто брал FSharpx.extras и FSharpPlus

Ну я просто брал FSharpx.extras и FSharpPlus

Да, так.

И всё работало

@artemy_b Я могу поискать, кстати, неплохую презентацию про внутренности FSharpPlus, если интересно.

В FSharpx.Extras просто много полезных дополнительных функций для Choice и Option

@artemy_b Я могу поискать, кстати, неплохую презентацию про внутренности FSharpPlus, если интересно.

Ну так-то интересно, да. Но, боюсь, там нужно будет долго вникать. Т.к. на данный момент не особо представляю, на что автору FSharpPlus пришлось пойти, чтобы добиться такого результата.

Там, наверное, дикие подвыподверты.

Ну так-то интересно, да. Но, боюсь, там нужно будет долго вникать. Т.к. на данный момент не особо представляю, на что автору FSharpPlus пришлось пойти, чтобы добиться такого результата.

Через патчинг компилятора!

Ммм, мечта!

Ну так-то интересно, да. Но, боюсь, там нужно будет долго вникать. Т.к. на данный момент не особо представляю, на что автору FSharpPlus пришлось пойти, чтобы добиться такого результата.

Да нет, там как раз всё достаточно нормально сделано.

Но фишка в том, что все реализации тайпклассов должны с собой тащить этот FSharpPlus

Или я путаю с FSharp.Control.Monad?

Сегодня пойти и починю. Теперь эта библиотека кажется мне очень важной. :)

Ты статью перевёл?

Вот этого не знаю. Я не пробовал c FSharpPlus чего-то серьёзного. Лишь один раз подключал для решения вышеописанной проблемы с >>=

Ты статью перевёл?

В процессе.

Держите презенташку от Томаша про сложности жизни в мире JS. http://tpetricek.github.io/Talks/2017/multi-runtime-challenges/

Кстати, новый сайт Fable менее симпатичный, чем старый (п -моему мнению).