Здравствуйте, alex_public, Вы писали:

_>Ну так это же речь не про встроенный в VM GC (как в JVM и CLR), а про доступ к некому внешнему.
Ты ж сам знаешь как доступ к внешнему работает. Работает на пинах объектов и опциональном счетчике ссылок поверх. Angular 1 именно тёк по памяти в Хроме из-за этого со страшной силой когда-то.
У меня лично претензий к такому интеропу нет, — я и на JS делал "disposable" и все компоненты кто держали ссылки должны были это делать нормально (зануливать). Иначе память убегала. Хоть это было и не так давно — но я боюсь все просто офигеют если элементы начнут течь в wasm, а средств отладки не будет. Опять же — их в этом случае не будет — объект отправился во вне — GC его не трогает и хорошо. Но хорошо кому?
Вы тут все такие умные и разрулите эти ситуации наверное, в идеале — не дав шанса им возникнуть. А в реале — будет, у "индусов" — будет иначе. Я просто очень плотно отлаживал утечки в JS, в основном свои. Не мои — это ангуляр. Смешное в ангуляре что у них и метод clear был, да ссылки не зануливал.
А ещё смешнее — что проблему поставили как баг Хрома т.к. в FF и IE на тот момент работало. Смешно прежде всего потому, что кто им блин обещал GC не на основе подсчета ссылок — неясно. А второе — жалко 3 строчки и экономия 80Мб на форме?!


_>Это если они вообще это реализуют, т.к. для интеграции web api этого не требуется (достаточно внешних дескрипторов), а требуется только для удобной (простая...
DOM и JS неявно требует GC. Вот только это. В остальном — любые API отлично ложаться на разные языки. Ну DOM API влезет даже в C++ без изменений практически.


PS: Впрочем если бы браузеры не писали приплюсплюснутые люди и в них бы не было жесткого подавления ошибок и константных конверсий между std::string и WTFString — то толку было бы всем больше безо всякого переписывания и новотеха. Одно другому не мешает конечно.