Благодаря за публикацията. Преходно това ще има голямо въздействие!

пляскане

Също така бях доста шокиран, че пляскането отнема по-голямата част от пространството в tokei дори повече от std .

От раздела .text да. Но не и целия двоичен размер, който всъщност беше единствената ми пречка за отчитането на товарите.

Като странична бележка, мисля, че хората всъщност използват по-малко std, отколкото бихте си помислили; няколко примитива, може би някои колекции и няколко черти. Не е така, сякаш всички std се включват, когато се компилират. Така че, когато хората видят, че std е доста малък в двоичния файл, но след това помислете за целия std lib, той надува умствената картина на всички останали щайги, изброени в резултата.

Всички предложения са добре дошли.

Относно раздела .text мога да направя --absolute флаг, който ще използва размера на файла като Общо или мога да отпечатам две колони: една за целия файл и една за .text .

Това ще бъде страхотно! Харесва ми идеята за две колони, защото някои може да не претърсят помощта, за да намерят --absolute. Въпреки това, с двете колони също би било добре да предоставите --no-absolute флаг за изключване на тази колона, ако някой не го иска по някаква причина.

Да. Съгласен съм, че най-добрият начин е да се показва всичко по подразбиране и да се деактивира чрез флагове.

Напълно съм съгласен, че този вид публикация е полезна! Благодаря, че го написахте!

Следващата стъпка отвъд разширяването на макросите по-малко пъти всъщност е подходяща за победа на контролера за заем (извинете,/u/jntrnr1) и вместо това използвайте функции, нали? Какви са пречките тук?

самоизменяеми, а след това заемът забранява да мутира всички полета на себе си, докато заемът е "на живо" и всичко се завърта в гигантска бъркотия. Това се усложнява, когато се опитвате да препратите към нещо от самата структура. Тъй като borrowck не може да надникне във функции, за да види, че не се случва нищо лошо, той просто го забранява изцяло.

Тук може да помогне нелексикалният живот. но тогава те също могат да бъдат малко ограничени при първоначалните имплементации. Правилният начин би бил разбиването на себе си на по-малки структури, но това би било основен рефактор. Така че бих искал бавно да работя към тази цел.

Има проблем със списъка с желания за частично заемане, което би помогнало за решаването на това.

Това е огромна болка и за мен и аз също използвах макроси само за да заобиколя този проблем.

Аз лично бих искал, ако Rust наистина надникне във функции и да види какви части от типове са заимствани във функцията.

Има два основни проблема с това. Първият е, че промяната на подробностите за изпълнението на дадена функция може да наруши потребителите на тази функция. Второто е, че може да е твърде скъпо и да забави компилацията.

Мисля, че първият може да бъде решен само чрез това вътрешно сандъче. Това би решило 90% от болката и всъщност не е нужно да предоставяте гаранции за API в същата щайга.

За второто всъщност не знам доколко това би забавило компилацията.

Разбирам защо заемката се оплаква, имам точно този проблем и в кода си. Това, което обаче не разбирам, е как макросите помагат в този случай.

Въпреки това, трябва да кажа, аз така или иначе едва разбирам макроси и никога не съм писал такъв.

Проблемът с извикванията на функции е, че функцията за проверка на заем не може да види какво прави функцията. Той проверява само подписа на функцията. Извикването на макрос се разширява до обикновен код, който проверката на заема всъщност анализира.

Ето един измислен пример (манеж):

Ако замените извикването на макрос с извикване на функция, инструментът за проверка на заеми ще се оплаче от заемане на псевдоними.