Никак, мап-редьюс не про это же?

Простой цикл решил бы твою проблему, кмк

https://habrahabr.ru/company/infopulse/blog/330708/ На ловца и зверь, @DmitryBubnenkov

Вдруг оказывается, что кто-то слышал что-то об одной классной вещи, а его коллега читал комментарий о другой на Хабре, а третий человек видел пост в блоге о ещё чём-то похожем… и вот мы уже пребываем в полнейшем ступоре, беспомощно барахтаясь в попытках выбора между совершенно противоположными по своей сути системами, уже и забыв, что мы вообще пытаемся выбрать и почему. Рациональные люди не принимают решения таким образом. Но именно так программисты часто решают использовать что-то вроде MapReduce.

помните я хотел заменять каждый второй символ? на aa или bb. Ну так вот. Вот код: line = line.enumerate.map!(a => a[0] % 2 ? "aa" : "bb").array.join; Пhоблема в том, что я не пойму как заменять не просто каждый первый и второй, а каждый первый и второй который равны к примеру c в строке kckckckc

Ну так внутри твоей лямбды достаточно проверить a[1] : если это 'c', то заменять, если нет, то оставить a[1].

У меня не полуичлось, я сделал циклом как @ahdenchik предложил. Сработало

Гоню.

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

Хорошие новости от LDC. Experimental integration of LLD, the LLVM cross-linker, for MSVC targets.

А вот у нас @nogc и nothrow вещи ортогональные? подразумевается что throw не использует GC?

скорее что non-nothrow использует @nogc

но они ортогональны)

угу, но ведь throw подразумевает new, а new подразумевает аллокацию класса?

как-то этот момент мимо меня проехал

вроде nothrow может Error кидать

а там аллокация используется

а, понял - используют самодельный аллокатор

https://github.com/caraus-ecms/tanya/blob/master/source/tanya/container/string.d#L617

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

точнее, это интерфейс, а аллокатор вот: https://github.com/caraus-ecms/tanya/blob/master/source/tanya/memory/mallocator.d

https://forum.dlang.org/post/weiktdahzvcqrzoejehk@forum.dlang.org свежие вакансии в социоматике

а, понял - используют самодельный аллокатор

нет import std.stdio; void foo(int k) nothrow { assert(k < 10); } void main() { foo(5); writeln("ok"); foo(12); writeln("never print"); }

core.exception.AssertError@/home/d210/f156.d(2): Assertion failure

эээ

но ведь nothrow

nothrow means that a function won't throw an exception. They can still throw errors. (errors are not supposed to be caught)

погоди, речь о @nogc была

всё равно компилится

может Error уже всегда аллоцирована и просто ждёт своего часа?

может Error уже всегда аллоцирована и просто ждёт своего часа?

может, но это в любом случае в std, а не в tanya

кроме ассертов есть и обычные эксепшены

которые уже конкретно аллоцируются

https://github.com/dlang/dmd/pull/6771 как в том анекдоте. "А жизнь-то налаживается"

Хотели же парсер в библиотеку выделить? Или это оно и есть?

Уже сделали в другом PR. Теперь делают dub script для того, чтоб это либу тянуть в проекты

блин постоянно забываю как сравнивать классы в compile time

is(T == int)

Не могли более интуитивно понятную конструкцию сделать

is уже слово было просто

можно было просто сравнивать как значения, наверно, но опять же, наверное, это вело к ошибкам

можно было просто сравнивать как значения, наверно, но опять же, наверное, это вело к ошибкам

is() поддерживает SFINAE. Так-что простого сравнения не хватилобы. У меня кстати есть предложение косательно улучшения is. Может быть как-нибуь напишу со всеми подробностями, хотябы здесь в чате, если не у них на форуме...

is() поддерживает SFINAE не совсем уловил при чём оно тут но ок

сейчас некогда, но потом подробней напишу. Если не забуду.

Да это ладно, а вот про улучшение is интересно

bool func()() if (!is(NeverExists!blablabla : NotDefined)) { return is(NotDefinedToo); } import std.stdio; struct Struct {} void main() { assert(func == false); } Этот код компилируется, хотя не должен, не должен не потому-что не соответсвтует правилам D (он вполне соответствует), а потому-что порождает ошибки, подобные ошибки были в стандартной библиотеке (да, той что phobos) , но их молча исправили и даже в списке изменений не упамянули про то что они вообще были. Вот как я считаю, выражение is(someSymbol), должно пораждать ошибку во время компиляции если идентификатор someSymbol не существует. Так, в примере что выше, таких ошибок 4-ре, т.к. символов NeverExists, blablabla, NotDefined, NotDefinedToo — несуществует. Я вовсе не предлагаю, что если ЕСТЬ символ symbol и у него НЕТУ поля field, то код is(symbol.field) должен порождать ошибку, я считаю что в таком случаи шибки недолжно быть. если котортко, то хочу так — код может компилироваться только в том случае, если несуществующий символ находится после точки, например is(symbol.notDefined) но не такой код is(notDefined). Вот мое предложение. я бы написал на форуме, но они скорее не поймут мой английский... У меня есть еще несколько предложений по языку, но пока-что лень писать.

Не понятно зачем это

чтобы было меньше ошибок.

А почему ошибки не должно быть если филд есть?

неважно есть там филд или нету, важно то, что первый символ должен быть всегда.

если его нету, то это явно ошибка.

Почему? там может static bool?

если его нету, то это явно ошибка.

... а существование какого-либо символа, должно проверятся какм-либо другим способом.

Почему? там может static bool?

примем покажи, а то я не понял о чем ты.

ну аргумент времени компиляции

а, is же

давай код.

не не сейчас никак

symbol возвращать тип разве не может?

охренеть! Действительно он не ругается на отсутствующие символы

if(symbol)

у нас же есть туплы типов

охренеть! Действительно он не ругается на отсутствующие символы

непонятно зачем так сделано

непонятно зачем так сделано

чтобы поддержать ISFINAE

что за ISFINAE?

пошел гуглить

ERROR: S client not available

дык отсутствие у всех подходящих типов определённого поля это всё равно ошибка

SFINAE без I, я просто опечатался.

дык отсутствие у всех подходящих типов определённого поля это всё равно ошибка

бля, я опять не понимаю о чем ты...

is() проверяет равенство или наличие типов

так?

типа is(bool == bool) == true

пишут, что это нужно для уменьшения сложности без жертв

пишут, что это нужно для уменьшения сложности без жертв

Что нужно?

http://forum.dlang.org/post/fs0dhv$29eo$1@digitalmars.com

какой старый тред

is() проверяет равенство или наличие типов

не совсем http://dlang.org/spec/expression.html#is_expression

ого я всё жизнь заблуждался

bool func()() if (!is(NeverExists!blablabla : NotDefined)) { return is(NotDefinedToo); } import std.stdio; struct Struct {} void main() { assert(func == false); } Этот код компилируется, хотя не должен, не должен не потому-что не соответсвтует правилам D (он вполне соответствует), а потому-что порождает ошибки, подобные ошибки были в стандартной библиотеке (да, той что phobos) , но их молча исправили и даже в списке изменений не упамянули про то что они вообще были. Вот как я считаю, выражение is(someSymbol), должно пораждать ошибку во время компиляции если идентификатор someSymbol не существует. Так, в примере что выше, таких ошибок 4-ре, т.к. символов NeverExists, blablabla, NotDefined, NotDefinedToo — несуществует. Я вовсе не предлагаю, что если ЕСТЬ символ symbol и у него НЕТУ поля field, то код is(symbol.field) должен порождать ошибку, я считаю что в таком случаи шибки недолжно быть. если котортко, то хочу так — код может компилироваться только в том случае, если несуществующий символ находится после точки, например is(symbol.notDefined) но не такой код is(notDefined). Вот мое предложение. я бы написал на форуме, но они скорее не поймут мой английский... У меня есть еще несколько предложений по языку, но пока-что лень писать.

Ну так что, кто-нибудь против моего предложиния, или может кто еще не понял его суть?

Не понятно как оно радикаьно жизнь упростит

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

... и не думаю что это будет сложно сделать тем, кто компилятор пишет.

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

а те кто заметят, скажут спасибо :)

ну странно что сразу так не сделано, кстати

видимо есть причина

при исправлении фобоса наверняка всплывало

просто об этом походу никто не думал. и да — всплывало но они дружно исправляли и молчали.

Написать по-русски и попросить перевести

Ну я написал, осталось только перевести.

что за ISFINAE?

Тут хорошо описано что это такое http://scrutator.me/post/2016/12/12/sfinae.aspx

Спасибо!

Бывалые C++ программисты знают, что возвращаемый тип в функции не является частью её сигнатуры, но даже многие бывалые не знают того, что возвращаемый тип является частью сигнатуры шаблона функции.

У нас тоже?

никогда не задумывался

У нас тоже?

да, тоже.

и вот как раз на этом строится проверка возвращаемого типа?

и вот как раз на этом строится проверка возвращаемого типа?

я опять не понял, про что ты?