и будет тебе nothrow

если хочется без GC, то добавляй @nogc, но тогда придется отказаться от большой части фобоса, от многих фишек с массивами. Короче тоже самое что и в betterC

лучше бы научили обычный режим избавляться от ненужного мусора

кстати, если ты в режиме betterC сделаешь new ты думаешь оно выдаст ошибку? А вот хрен там. Ошибка вылезет только на стадии линковки

кстати, если ты в режиме betterC сделаешь new ты думаешь оно выдаст ошибку? А вот хрен там. Ошибка вылезет только на стадии линковки

ну это логично, betterC родился личным костылем Уолтера, и до сих пор остается костылем)

по сути, кроме линковки он ничего и не меняет

ну это логично, betterC родился личным костылем Уолтера, и до сих пор остается костылем)

я об этом же

по сути, кроме линковки он ничего и не меняет

до последнего времени он еще и не умел деструкторы вызывать, сейчас умеет и смысл совсем потерялся

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

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

именно

как по мне, BetterC имеет право на жизнь в качестве «низкоуровневого» диалекта языка

эдакая удобная штука для того, чтобы не линковать всё, что нужно не линковать)

как по мне, BetterC имеет право на жизнь в качестве «низкоуровневого» диалекта языка

но для этого он должен отсекать все недопустимые операторы на стадии компиляции.

ну так и развивать его надо в этом направлении, не всё же сразу)

эдакая удобная штука для того, чтобы не линковать всё, что нужно не линковать)

ну вообще-то так должно быть всегда, даже без betterC. Зачем линковать то что не нужно линковать?

Ну да, должно быть, но по факту нет

ну вот видишь, деструкторы не вызывались из-за того, что завязаны на рантайм, scope(exit) туда же, потом это починили)

осталось дать возможность перегрузки new и delete, и получим BetterC++

осталось дать возможность перегрузки new и delete, и получим BetterC++

Тогда мы уже приблизимся к D 3.0

а то delete вообще объявлен deprecated уже лет 10 как :)

10 конечно утрированно, но очень давно

кстати new можно перегрузить через зад, оторвав стандартный рантайм, и написав свой вариант.

кстати new можно перегрузить через зад, оторвав стандартный рантайм, и написав свой вариант.

так можно много всего сделать, например, нормальный GC или GC на выбор, как в яве)

D3 все же нужен... много лишнего наворочено

Ди во вторые плюсы превращается

А что бы ты убрал?

мне кажется, только со всякими атрибутами намудрили, остальное пока ок)

safe по дефолту, выкинуть inout

транзитивный const и immutable - в пень

safe по дефолту поломает старые исходники)

ну так это же D3

D2 и D1 тоже несовместимы

ну ради атрибутов форкать язык и делать его несовместимым — не рационально)

так можно много всего сделать, например, нормальный GC или GC на выбор, как в яве)

GC на выбор уже есть только его писать надо

ну ради атрибутов форкать язык и делать его несовместимым — не рационально)

нетранзитивность квалификаторов тоже очень серьезное изменение, ну GC выкинуть или сделать ARC

GC на выбор уже есть только его писать надо

any color you like as long as it's black (с)

я бы вообще сделал бы все как в плюсах , только с дишным синтаксисом

идеальный для меня язык

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

А что бы ты убрал?

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

Миксины так просто убрать нельзя, только на макросы заменить

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

Ряд конструкций сделал бы попроще. Уж больно мне for in в питоне нравится

Свитч бы выкинул и паттерн матчинг сделал бы вместо него

Ряд конструкций сделал бы попроще. Уж больно мне for in в питоне нравится

ну это уже вкусовщина

Просто надо чтобы язык не был избыточным

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

Но вот стандартный event loop был бы весьма кстати, не хватает его очень. Приходится пилить 2 версии программ - для стандартной библиотеки и для vibe

Свитч бы выкинул и паттерн матчинг сделал бы вместо него

нормальный паттерн-матчинг не сделаешь, а если и сделаешь, то получится хаскель

А легкую асинхронность хочется использовать почти всегда.

Но вот стандартный event loop был бы весьма кстати, не хватает его очень. Приходится пилить 2 версии программ - для стандартной библиотеки и для vibe

ну встраивать его в язык я бы не стал, в фобос можно, и попытки это сделать есть

switch - норм, у нас тут не ФП

От switch'a до pattern matching'a уже рукой подать, их можно весьма органично объединить: https://code.haxe.org/category/beginner/pattern-matching.html

такой паттерн-матчинг достаточно примитивен

но его можно реализовать, наверное

такой, честно говоря, не особо нужен

хотя матч по структурам неплох, да

транзитивный const и immutable - в пень

чем не нравится?

и чем mixin'ы не нравятся? отладка сложновата, но в остальном инструмент отличный

кстате лол http://m.cnews.ru/news/top/2018-02-08_v_rossii_napishut_svoj_obektnoorientirovannyj

что за защиту данных там придумали я не понимаю

просто похоже на очередной распил, целесообразности не вижу

если кто-то понял про модульную защиту данных, объясните пожалуйста)

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

Без прочтения како-нибудь нормального whitepaper (как сейчас модно это называть) даже обсуждать особо не имеет смысла.

ну тоже верно

кстате лол http://m.cnews.ru/news/top/2018-02-08_v_rossii_napishut_svoj_obektnoorientirovannyj

"Sawfel"

На форуме опять про D3 говорят

ERROR: S client not available

Ну вот про go например тоже очень много говорят, но все их крики про дженерики и исключения тупо игнорятся. И нормально плывут.

Зачем строить свою иерархию? Просто не используй new

а как это выглядит практически в таком случае - я пишу библиотеку, которая может бросать nongc екскпшны. Я должен в доке библиотеки сказать юзеру что он в catch должен вызывать dispose на exception (или как оно зовется в случае аллокаторов)?

а как это выглядит практически в таком случае - я пишу библиотеку, которая может бросать nongc екскпшны. Я должен в доке библиотеки сказать юзеру что он в catch должен вызывать dispose на exception (или как оно зовется в случае аллокаторов)?

да, а как иначе?

ну юзер будет забывать, будет течь

проблема только в этом

На форуме опять про D3 говорят

Ссылку на срач сюда

Это не спортивно - вбросить и уйти :)

https://forum.dlang.org/thread/mvhddaendngqwbmlzdei@forum.dlang.org

проблема только в этом

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

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

А нельзя ли в деструктор класса запихнуть самоочистку?

А нельзя ли в деструктор класса запихнуть самоочистку?

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

Хм ну тогда, насколько я помню, ведь можно эту выделяемую память вручную добавить в писок GC

https://wiki.dlang.org/Memory_Management

// allocate memory for the object auto memory = malloc(size)[0..size]; if(!memory) { import core.exception : onOutOfMemoryError; onOutOfMemoryError(); } writeln("Memory allocated"); // notify garbage collector that it should scan this memory GC.addRange(memory.ptr, size);

дык фишка-то в том, что GC не используется, иначе зачем все эти пляски?

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

void heapDeallocate(T)(T obj) { import core.stdc.stdlib : free; import core.memory : GC; // calls obj's destructor destroy(obj); // garbage collector should no longer scan this memory GC.removeRange(cast(void*)obj);

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

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

а накой вообще исключения выделять в куче?

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

статически выделить память, менять поля перед выбрасыванием

а накой вообще исключения выделять в куче?

что бы использовать их в nogc коде

что бы использовать их в nogc коде

описал то, про что я говорю выше

так же nogc

статически выделить память, менять поля перед выбрасыванием

как вариант

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

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

Если включен, то тогда разработчик проекта может использовать твои эксепшены как обычно и они будут нормально подищаться GC, но при этом вся библиотека nogc совместима.

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

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

Это должно выглядет как метод самого Exception видимо

catch (Exception e) { ... e.dispose(); }

То есть голый destroy запрещен

статически выделить память, менять поля перед выбрасыванием

отговаривают от этого, говорят что грязный хак. аргументы не понял, но подробности есть на dlang idioms