MP
да компа там нормального нет
Есть, полноценные инстансы.
Size: a a a
2020 October 20
(L
Контр аргумент не понял, раскроешь мысль?
p
Ну и я про то. Обертки над обёртками
Чтобы передать ф-ю с именованным параметром как генерик, нужна неименованная, которая дёргает именованную
Чтобы передать ф-ю с именованным параметром как генерик, нужна неименованная, которая дёргает именованную
А можно просто не делать имена в трейтах функции, как в мейнстримных языках.
в🧇
Ну и я про то. Обертки над обёртками
Чтобы передать ф-ю с именованным параметром как генерик, нужна неименованная, которая дёргает именованную
Чтобы передать ф-ю с именованным параметром как генерик, нужна неименованная, которая дёргает именованную
Так функция с именованными аргументами всё равно имплементирует
Fn* трейты, не понял проблемы.в🧇
Контр аргумент не понял, раскроешь мысль?
fn fun(Type(..): Type) {}
Какое имя у первого аргумента?p
fn fun(Type(..): Type) {}
Какое имя у первого аргумента?_0
ШН
Mag Pie
Есть, полноценные инстансы.
Знаю я такие инстансы, работают с вытеснением. Выделить один рабочий ноут разраба, и уже было бы не 5 дней, а 4 дня и 20 минут
в🧇
ну и зачем такие имена?) У имён весь смысл — показывать мешку с мясом что параметр значит.
_0 вообще ни о чём не говоритp
Знаю я такие инстансы, работают с вытеснением. Выделить один рабочий ноут разраба, и уже было бы не 5 дней, а 4 дня и 20 минут
Напиши им, в чем проблемы?
ШН
Напиши им, в чем проблемы?
Куда им? Как будто они слушают кого-то, ага
p
ну и зачем такие имена?) У имён весь смысл — показывать мешку с мясом что параметр значит.
_0 вообще ни о чём не говоритНи разу не видел в реальном коде деструктуризацию в функциях. Так что можно пренебречь этим кейсом и сделать генерацию имён _0, _1, _2.
p
Куда им? Как будто они слушают кого-то, ага
Разрабам
ШН
Разрабам
Им легче бота запилить, который эмози удаляет.
(L
ну и зачем такие имена?) У имён весь смысл — показывать мешку с мясом что параметр значит.
_0 вообще ни о чём не говоритНу тут мешок с мясом видит, что происходит деконструкция, и смотрит уже на имена того что деконструировано
Согласен, несовместимый кейс
Согласен, несовместимый кейс
AZ
Куда им? Как будто они слушают кого-то, ага
каждый голос будет услышан
ШН
каждый голос будет услышан
Э
Так не вмёржили же. Да и это Centril, его иногда заносит.
ШН
Так не вмёржили же. Да и это Centril, его иногда заносит.
Осадочек остался ведь 😂
Э
Осадочек остался ведь 😂
От твоего недовольства осадочек тоже остаётся, так что, банить тебя?
AZ
мотивация очень интересная:
"Currently, some RFCs get a lot of down-votes. This can be especially frustrating and discouraging for new users to the RFC process and Rust community in general. Spending a lot of time on writing an RFC only to have it down-voted a lot may be very bad for the self-esteem of the user which may cause the user to not continuing on improvements or writing an RFC in the future.
Down-votes also have somewhat of an avalanche effect - if one user has down-voted a proposal, it becomes easier to down-vote even without reading the proposal in-depth.
A more friendly and constructive way of disagreeing or showing disapproval, either of details, or the proposal in general, is for one (or several) persons to comment on what they are disagreeing with, and then other people can upvote those comments to show that they agree with that particular perspective. This method of discussion also provides context to the author allowing the author to makes changes to the proposal that are in the direction requested by the user commenting.
This costs more than habitual drive-by-downvoting, but helps the user and the RFC process more, which in turn helps the Rust community at large more.
Therefore, this is a plea for people to not down vote and instead up-vote good comments (and to not down-vote comments either). This is about self-policing and showing respect for the work and ideas of others. And not currently about enforcing a policy (i.e: “legislation”)."
"Currently, some RFCs get a lot of down-votes. This can be especially frustrating and discouraging for new users to the RFC process and Rust community in general. Spending a lot of time on writing an RFC only to have it down-voted a lot may be very bad for the self-esteem of the user which may cause the user to not continuing on improvements or writing an RFC in the future.
Down-votes also have somewhat of an avalanche effect - if one user has down-voted a proposal, it becomes easier to down-vote even without reading the proposal in-depth.
A more friendly and constructive way of disagreeing or showing disapproval, either of details, or the proposal in general, is for one (or several) persons to comment on what they are disagreeing with, and then other people can upvote those comments to show that they agree with that particular perspective. This method of discussion also provides context to the author allowing the author to makes changes to the proposal that are in the direction requested by the user commenting.
This costs more than habitual drive-by-downvoting, but helps the user and the RFC process more, which in turn helps the Rust community at large more.
Therefore, this is a plea for people to not down vote and instead up-vote good comments (and to not down-vote comments either). This is about self-policing and showing respect for the work and ideas of others. And not currently about enforcing a policy (i.e: “legislation”)."