Показываю код https://github.com/rustyio/sync/blob/master/src/sync_scanner.erl#L142

Нет, если только новый тип func вдруг случайно не совпал с типом func2.

как на счёт неавных преобразований?

Разве не проще тогда чтобы любая конструкция языка возвращала что-то осмысленное?

будет синтаксический шлак в коде. Придётся вводить специальный тип вроде None (или юзать существующий) и им терминировать каждую void'ную.

Не, вобще-то надо просто посмотреть на последнее выражение функции.

последнее выражение if/case внутри с ещё кучкой if/case'ов

Скорее объект какого-то класса, а это уже совсем другое.

Нет, объект самого класса. У него есть dict'оподобный интерфейс. Соответственно, делать с ним можно примерно всё тоже самое.

как на счёт неавных преобразований?

Не нужны.

Придётся вводить специальный тип вроде None

Нет, не придется.

последнее выражение if/case внутри с ещё кучкой if/case'ов

Как хорошо что в эрланге такого нет.

Кроме того что нельзя просто вызвать функцию, нужно откуда-то получать правильный объект (привет синглетоны).

как жаль что питон не параллельный, да? Ты это хотел сказать? :D

Я хотел показать что многострочные функции бывают удобны независимо от того есть у них имя или нет, функция с именем не связана.

Вот тут неплохое опровержение http://udpn.livejournal.com/96474.html?nojs=1 ;)

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

Так толсто...

... что даже и тонко.

Ты покажи что это входит в стандарт языка, а не фичу конкретного компилятора.

Ну, во-первых, в Linux gcc вполне стандартен (не со шлангом же, ей Богу «развлекаться»). Во-вторых, если говорить о питоне и пытаться сравнивать стандарты C со стандартами питона то их, простите нет у питона. Сравнивать не с чем. Просто не с чем. И, наконец, в третьих, обсуждаемые нами nested functions в gcc появились, ЕМНИП, в году 2007-08. Время на закрепление в стандарте примерно известно — порядка 10 лет. Так что, скорее всего, увидим, но чуть позже.

жму Вашу руку!

Я же написал, что на данный момент такие выражения не компилируются, но если делать return опциональным они должны работать.

И непонятно какое выражение считать последним в случае

void f1(int x) { /* много кода */ }

int f(int x) 
{
  x+1;
  f1(x);
}

Потом её немного рефакторят, делают ф-ю с возвращаемым значением забывая дописать конец.

Получается валидная с точки зрения языка ф-я и UB с точки зрения логики

И при этом тип совпал? Ну, если уж придумывать сценарии ошибки, то пусть будет такой: при рефакторинге просто дописали return перед последним оператором.

Смотрит он на реализацию type func() и аналогичные ф-ии, нигде не ясно забыли ли вернуть осмысленное значение или нет.

У нас априори язык, в котором возвращается последнее вычисленное значение, так что вопрос «забыли или нет» не стоит.

Почему-то на эрланге работают высоконагруженные кластеры и никто не жалуется.

на PHP тоже

Это ты не мне отвечаешь.

нужно рассказать что такое неявное приведение типов, copy constructor и про прочие прелести ООП-подобных ЯП?

Нет, не надо. Это Си++-проблемы, но в Си++ никто и не собирается добавлять обсуждаемую возможность.

И непонятно какое выражение считать последним в случае

Последнее по тексту. В чем проблема с этим подходом?

В чем проблема с этим подходом?

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

В чем проблема с этим подходом?

Проблема в том что он негодный.

Веско, убедительно.

Код не должен превращаться в ребус.

Не превращай.

Не превращай.

Веско, убедительно.

Ох уж эти рационализаторы. поубивал бы всех нах!

Ох уж эти рационализаторы. поубивал бы всех нах!

Тебе слабо.

Сорри, t маленькая. т.е. Qt - is a cross-platform application and UI framework

А как можно считать последним x+1, если оно не последнее? Например, так это работает в руби:

$ cat > 1.rb <<EOF
def foo
  1
end

def bar
  2 + 2
  foo + 5
end

puts bar
EOF

$ ruby 1.rb
6

Компилятор допускает конструкции вида

int f1(T)(T x) { return x; }
void f1(byte x) { }

Я не знаю ruby. В нем функция может не возвращать значение?

со стандартами питона то их, простите нет у питона.

И это еще одна причина почему питон говно.

Это понятно, просто непонятно зачем писать такой код, про который заведомо известно что он не будет выполнятся. Это все равно что писать if (0) { ... }.

Допустим есть функция

int foo(int x) { return x+1; }

int foo(int x) { x+1; } 

Хм. Чем оно лучше Си?

Или вот ещё

int foo(int x) {
    for (int i=0; i<10; i++)
        x += i;
}

Результат for, естественно. А он будет равен результату последнего выражения в теле цикла на последней итерации.

Результат какого выражения должен возвращаться.

Ответ на этот вопрос зависит от того, какой тип имеет конструкция for. Было бы естественным, что это void (или unit), и тогда программа ошибочна, компилятор должен ее отвергать.

Согласен, естественнее было бы void. Если же посмотреть на хаскель, там был бы список из результатов каждой итерации.

Список тоже логичен, но и в этом случае программа не пройдет проверку типов.

Ну и круто, в чем проблема то?

Я уже нашел замену С++, действительно классную - Mozilla Rust. Вот если бы плюсы были такие, то софт действительно был бы лучше

То есть нужно, чтобы все инструкции возвращали значения, какое то соглашение когда функция должна возвращать структуру, инстанс, делегат и т.д. Возможно что то ещё.

ИМХО делать это только для того, чтобы иметь возможность иногда не писать return неправильно.

Удивительно, как с этим справляется хаскель, да?

Я уже нашел замену С++, действительно классную - Mozilla Rust

и как, много уже на нем написал?

То есть нужно, чтобы все инструкции возвращали значения, какое то соглашение когда функция должна возвращать структуру, инстанс, делегат и т.д.

То есть каждая конструкция языка должна вырабатывать какое-то значение.

ИМХО делать это только для того, чтобы иметь возможность иногда не писать return неправильно.

Оно делается для усиления выразительности вообще. Возможность не писать return - только один из профитов.

Mozilla Rust. Вот если бы плюсы были такие

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

Хаскеля я, к сожалению, не знаю, но если создавать новый язык, с учетом этого тогда проблем не будет (или просто использовать язык, где такая возможность есть). Если же попытаться добавить такую возможность в существующий язык то получим трехгорбого верблюда на костылях.

В любом случае это потребует сильно переделать язык.

А какие ещё профиты можно получить? Мне в голову приходит только возможность убрать return вообще. Чтобы у функции была только одна точка возврата.

Нативный байндинг к libc regex. С его помощью допишу аналог комманды sort. Потом буду писать небольшой сервачек

Ясное дело, не готовая сырая альфа. А концепции очень крутые

Ясное дело, не готовая сырая альфа

В том-то и дело, что это уже далеко не альфа.

Альфа такая что прямо дымится. Версия 0.8. До 1.0 разработчики оставляют за собой право как угодно ломать библиотеки и менять синтаксис языка.

С каждым релизом дохнут все библиотеки и фреймворки. Их уже перестали писать, ждут 1.0

Альфа такая что прямо дымится.

Сырой альфой были первые версии Rust, когда у руля был Хоар; сырой бетой Rust был перед его уходом; сейчас уже упорно говорят о 1.0, при этом окончательного консенсуса о фичах еще нет. Так что в результате они либо упустят время и говноGo всё зохавает, либо они выпустят незавершенный язык.

говноGo

ГовноGo зохавает не все, а нишу замены С++. Ну как бы нишу не С++, а именно нишу замены C++, если ты понимаешь о чем я ;)

И именно потому что Google > Mozilla и Go готов сейчас. Будь Rust хоть во всем круче.

А чем в таком случае...

... лучше эрланг? Из языка, изначально предназначенного для решения специфичных для «телекома» задач, его тянут куда ни попадя. Получится как с перлом — из языка обработки логов, его затянули куда ни попадя и потом похоронили (в основной массе для индустрии он скорее мёртв чем жив).

В то же время, С как жил, так и живёт. /* С в другом неповезло — похожий на С синтаксис был использован для семантически отличного от С языка. И это даёт повод упоротышам с разных сайтов писать «почему D лучше С++», но при этом у них не включаются мозги чтобы не писать «С/С++». Что там за D они изволят напейсать, мне неведомо. Меня скорее интересует вопрос насколько сильно их контузило. При таких «подходах». */

А какие ещё профиты можно получить?

Примерно те же, что от тернарного оператора в Си или if-выражения в Питоне - строк кода меньше.

 let mut response = match request.read_response() {
        Ok(r) => r,
        Err(_) => {
            start_sending(start_chan, Metadata::default(url)).send(Done(Err(())));
            return;
        }
    };

Мне в голову приходит только возможность убрать return вообще. Чтобы у функции была только одна точка возврата.

Это просто побочный эффект, тем более, что return не обязательно убирать из языка. В Rust он есть, например.