Vlákno názorů k článku Rust: předávání parametrů referencí, elegantní způsob práce se sekvencemi od robotron - (Nevim, jestli nahodou nenarazim na totez, co myslel...
-
robotron (neregistrovaný)
(Nevim, jestli nahodou nenarazim na totez, co myslel vyse Jvr z VSE.) Vsechno se mi to libi, ale tohle me desi:
pokud z funkce pass_by_reference odstraníte hvězdičky (operátor dereference), proběhne překlad v pořádku. Totéž platí i při volání funkce, kdy je možné zapsat znak & kolikrát chcete. Je to zvláštní a užitečný důsledek silné typové kontroly a typové inference.
Je pro takovehle chovani nejaky rozumny duvod? Mam pocit, ze kdekoli byla v normach benevolence, vetsinou to dost hrozne dopadlo. Viz rana leta HTML, kdy se kazda jedenapulta prirucka chvastala, jak je to bozi, ze lze napsat <a><b></b> a AI si to sama spravne prebere. Jak tenhle trend dopadl, vsichni vime. Jelikoz ale predpokladam, ze za vznikem Rustu je mozek a ne tarot, mozna to nejaky vyznam ma, jen mi proste nedochazi.
-
Pavel TišnovskýZlatý podporovatelOno je těch "magických" konverzí ve skutečnosti ještě víc, docela hutně je to popsáno tady:
https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.mdU těch referencí je to celkem šikovná věc, protože se v tomto místě překladač IMHO nemůže "splést" - při volání přesně ví, jaký typ přesně očekává, navíc ví, že programátor explicitně vytvořil referenci.
-
Hm. Překladač sice ví, ale otázka je, zda ví (v daném kontextu) i člověk, který ten kód čte...
IMHO čím víc implicitního chování, tím hůř se kód chápe a to má v důsledku vliv na cenu a kvalitu. Přecejen pořád platí, že jednou napsaný kód bude stokrát přečtený... Naprosto souhlasím s robotronem, že jazyk by měl být poměrně striktní, co se zápisu týče.
-
Pavel TišnovskýZlatý podporovatel
Souhlas, je nutné vybírat, co by měl ještě jazyk dělat automaticky ("domýšlet") a co už ne. Zrovna automaticke dereferencovani ale podle me v Rustu uz zustane (proslo to pres verzi 1.0), takze jsem povazoval za dobre se o tom v clanku zminit (ono to bude asi vice zrejme pri popisu struktur).
-
bumblebee man (neregistrovaný)
> Hm. Překladač sice ví, ale otázka je, zda ví (v daném kontextu) i člověk, který ten kód čte...
Otazka je, zda to ten clovek potrebuje vedet ;-) Ve vetsine pripadu kdyz mam:
obj1->obj2.obj3->obj4
je pro me dulezite ze pristupuju k atributum objektu, a to ze nekde musi byt "." a jinde "->" je pro me jenom informacni sum... ;-)
-
Radek Miček (neregistrovaný)
Modifikator out je pozustatkem doby, kdy mainstreamove jazyky neznaly tuple
outmůže být v mnoha situacích přehlednější, pokud jazyk neumí tuple s pojmenovanými prvky (jako třeba Swift) neboli anonymní záznamy.Navíc
outmůže být efektivnější, pokud se tuple alokuje na heapu a kompilátor tuto alokaci neeleminuje. -
Inkvizitor (neregistrovaný)
> out může být v mnoha situacích přehlednější, pokud jazyk neumí tuple s pojmenovanými prvky (jako třeba Swift) neboli anonymní záznamy.
To jako ze chce vracet zpatky treba 5 hodnot? Tam uz je to podle me na explicitni typ.
> Navíc out může být efektivnější, pokud se tuple alokuje na heapu a kompilátor tuto alokaci neeleminuje.
Pokud ale dany jazyk ma neco spatne, tak by bylo namiste to spis opravit, namisto takoveho pseudoreseni.
-
Radek Miček (neregistrovaný)
kde by byl problem v nepojmenovani dvou hodnot ve dvojici
Často je to problém, když funkce vrací 2 hodnoty stejného typu (snadno dojde k jejich záměně). Nebo když takových dvojic používáte více na jednom místě (např. v jedné funkci).
Nevýhodou pozičního pattern matchingu (tj. když záleží na pořadí) je, že kód příliš nezpřehlední, když jsou tuply vnořené, další nevýhodou je, že pro přidání fieldu do tuplu musíte upravit všechna místa, kde tuple srovnáváte se vzorem (zatímco, když si fieldy pojmenuje, tak není třeba nic upravovat).
-
Pokud je jazyk staticky typovaný, typ byste musel explicitně vytvářet tak jako tak, jen by možná byl inline, takže by nepotřeboval jméno. Takže jméno je to jediné, co potřebujete navíc. To není až tolik?
Ale jak pracovat s takovýmto inline typem? Pokud bych z nějakého důvodu chtěl explicitně otypovat výstup z té funkce (pokud ho budu chtít předávat jinam, bude se to docela hodit…), najednou ten pojmenovaný typ bude praktičtější.
-
Radek Miček (neregistrovaný)
Takže jméno je to jediné, co potřebujete navíc. To není až tolik?
Potřebuji celou tu deklaraci, ne? Tj. jméno + seznam fieldů + jejich typy. Když třeba píši SQL dotazy, přijde mi už docela dost práce pro každý dotaz vytvářet pojmenovaný typ. A vracet z SQL dotazů tuply je z mé zkušenosti v F# docela nepřehledné (ale bohužel LINQ v F# nic lepšího neumožňuje).
Pokud bych z nějakého důvodu chtěl explicitně otypovat
S tím samozřejmě souhlasím.
-
> seznam fieldů + jejich typy
Což bych ale musel uvádět tak jako tak, přinejmenším ta jména jo. Typy by si kompilátor mohl teoreticky odvodit, ale otázka je, nakolik by to bylo best practice. Třeba u Scaly se považuje za best practice mít explicitní typové anotace u návratových hodnot v public API., což mi přijde rozumné.
Ano, daly by se najít případy, kdy by jazyk mohl poskytnout pohodlnější řešení návratových hodnot. Třeb vracím pět různých hodnot a nejsem v public API a typ pojmenovat nepotřebuju. Ale jak je to často? Pokud moc ne, nevedlo by to spíše k málo známé syntaxi, která čtenáři zkomplikuje čtení kódu?
-
Radek Miček (neregistrovaný)
Ale jak je to často?
Mně to právě přijde docela časté - SQL, Spark, n-tice, která je použita pouze jako návratová hodnota jedné funkce, automaticky generovaná schémata z různých formátů (kolikrát z formátů typu JSON není patrné, jak záznam pojmenovat nebo to dokonce ani nemá rozumný název).
Na mnoha místech, kde se dnes používají dvojice, trojice nebo nedej bože n-tice pro n>3, by šlo použít anonymní záznam / tuple s pojmenovanými složkami a zlepšilo by to čitelnost, zabránilo některým chybám a umožnilo snáze přidat další složku.
Podobná situace je mj. i s algebraickými datovými typy - mnoha jazykům chybí anonymní a místo toho používají Either (někdy i vnořený nebo Either3), kde z typu funkce nic nepoznáte.
Což bych ale musel uvádět tak jako tak, přinejmenším ta jména jo.
Jména můžete vzít z proměnných, která do záznamu ukládáte nebo ze sloupců v SQL dotazu, typ záznamu se pak inferuje.
-
Inkvizitor (neregistrovaný)
Mně se moc nelíbí, že pořád hledáš, jak odůvodnit špatné (resp. nedokonalé) řešení problému způsobeného jiným špatným rozhodnutím nebo absencí nějaké další featury. Pojďme se pobavit o tom, jak a zda by se dal vylepšit Rust/Scala/F#/Haskell nebo já nevím co, aby se to nemuselo záplatovat nějakým zhůvěřilostmi jako je "výstupní parametr".
Pobavila mě diskuse na fóru Rootu, kde se řeší, jaký chaos by nastal při zrušení primitivních typů v Javě, protože by se někde ve volání funkce mohl objevit null. Přičemž samozřejmě jde o to, že tu chlívárnu jménem null vůbec do Javy tvůrci zavlekli, protože neznali Option/Maybe a pattern matching nebo se domnívali, že je to moc složitý koncept pro programátory v Javě.
-
Radek Miček (neregistrovaný)
zda by se dal vylepšit Rust/Scala/F#/Haskell
Však říkám - přidat anonymní záznamy a umožnit, aby se nemusely alokovat na heapu.
Koneckonců o anonymní záznamy se ve Scale a Haskellu pokouší různé knihovny. Problém je, že tyto knihovny se většinou nepoužívají úplně pohodlně - proto se třeba uvažuje o přidání záznamů do Dotty - viz https://github.com/lampepfl/dotty/issues/964 A kdysi se to zvažovali i pro GHC Haskell http://research.microsoft.com/en-us/um/people/simonpj/Haskell/records.html (Hugs měl Trex). Pro F# rovněž existuje návrh https://github.com/fsharp/fslang-suggestions/issues/207 , ale nejspíš nebude v brzké době implementován, protože se neví, jak to implementovat nad CLR, aby to bylo efektivní.
-
ded.kenedy (neregistrovaný)
Přičemž samozřejmě jde o to, že tu chlívárnu jménem null vůbec do Javy tvůrci zavlekli, protože neznali Option/Maybe a pattern matching nebo se domnívali, že je to moc složitý koncept pro programátory v Javě.
Se ti to dobre keca z pohledu roku 2016. Ale uvedom si, kdy zacinal vyvoj Javy a kdy byly zverejnene prvni verze, tj. prvni polovina devadesatych let, kdy bezne pocitace mely procesory i286-386 a 1 az 4 MB pameti RAM. Tam uz kazda alokace navic pro Optional/Maybe je znat. Ke vsemu jeste Java nebyla urcena pro bezne PC ale pro embedded zarizeni, takze tam to bylo s moznostmi HW jeste horsi. Z pohledu navrha jazyka jsou primitivni typy vetsi zlo nez null. Pricemz, ze by null byl nejake velke zlo, se zacatkem devadesatych let moc neresilo, lidi meli s pocitaci jine starosti.
-
Radek Miček (neregistrovaný)
tu chlívárnu jménem null vůbec do Javy tvůrci zavlekli, protože neznali Option/Maybe a pattern matching nebo se domnívali, že je to moc složitý koncept pro programátory v Javě
Dnes jde
nulldocela pěkně ošetřit typovým systémem (viz třeba Kotlin). Takový kód v Kotlinu je elegantnější než obdobný kód ve Scale sOption.Je otázkou, zda
Optionplně řeší problémnull, v situaci, kdy máte proměnnou (nebo field), do níž přiřazujete a která může v určité části programu (např. při inicializaci) býtNonea v určité části programu ne. Takto přesný typ většina jazyků nedokáte vyjádřit, tudíž programátor musí použít aproximaci, která jednoduše řekne, že proměnná je typuOption- tj. v části kódu, kde proměnná nemůže býtNone, je na tom podobně jako snull. -
> může v určité části programu (např. při inicializaci) být None a v určité části programu ne
Inicializace – to řeší (v tak 99 % případů) třeba modifier final v Javě.
> tudíž programátor musí použít aproximaci
I to se může stát. Rozdíly mezi null a Option:
* Option lze vnořovat, nullability ne.
* Null bývá přesně z tohoto důvodu efektivnéji implementovaný. I když nmusel by, ve Scale jsem se pokoušel implementovat vlastní Option, která by se překládala interně na null, kde by to šlo. (Nešlo by to třeba u vnořených Option nebo u generičtějšího kódu.) Bohužel jsem tehdy narazil na nějaký bug.
* Neumí-li jazyk dobře pracovat s nullability, hodnota null může překvapit. Programátor bude tiše předpokládat, že se null objevit nemůže, zkompiluje se to a za běhu (třeba až na produkci…) se tam null objeví. Aby se to stalo u Option, musel by programátor například vědomě zavolat get(). V tak 99 % případů se bez get() lze obejít.
* S Option lze dělat map/filter/exists/… Pravda, u null to v principu jde také. -
Radek Miček (neregistrovaný)
Inicializace – to řeší (v tak 99 % případů) třeba modifier final v Javě.
Zrovna v Javě je problém s tím, že metodu nejde volat s pojmenovanými argumenty - tj. volání metod s mnoha argumenty jsou nepřehledná, tj. u objektů, kde je k inicializaci třeba mnoho argumentů, je použití konstruktoru nepřehledné. Pokud se tedy inicializaci rozhodnete provádět mimo konstruktor,
finalnepomůže.Neumí-li jazyk dobře pracovat s nullability, hodnota null může překvapit.
Souhlasím, je to spíš problém konkrétní implementace než problém
null.implementovat vlastní Option, která by se překládala interně na null, kde by to šlo.
BTW F# to takhle má implementované (na CLR jde volat metody, i když je
this == null). -
uetoyo (neregistrovaný)
"Zrovna v Javě je problém s tím, že metodu nejde volat s pojmenovanými argumenty - tj. volání metod s mnoha argumenty jsou nepřehledná, tj. u objektů, kde je k inicializaci třeba mnoho argumentů, je použití konstruktoru nepřehledné. "
Tohle se řeší nějakým návrhovým vzorem ne? To, že můžu pojmenovat argumenty je pěkné, ale když mám konstruktor s 20 argumenty, ani to mi nepomůže. Rust právě hojně používá Builder Pattern.
-
Radek Miček (neregistrovaný)
Rust právě hojně používá Builder Pattern.
Jenže v Javě vás Builder nezachrání před
null(kompilátor Javy nijak nezabrání dereferencinullv metodách builderu - afinalnejde v builderu použít, pokud bude builder měnit hodnotu proměnné).ale když mám konstruktor s 20 argumenty, ani to mi nepomůže.
Proč?
-
tisnik (neregistrovaný)
Tak ono mnohdy stačí umět na null správně reagovat a ne hned házet NPE. Prostě chápat null jako "tady není žádná hodnota" a ne "tady není nic a strašně se s tím musíš poprat". Jo když se to chápe rigidně, tak i klasický výraz "Hello " + name musíš obalit checkem na not null. Takové Clojure na to kašle, prostě (str "Hello " name) nikdy nehodí NPE (tady to tak nevypadá, ale ve složitějším kódu, kde se dělá pipa pomocí makra -> to v podstatě ušetří hromadu zbytečných if-ů)
-
> SQL
Tam typicky chci ten typ i pojmenovat, protože se bude předávat dál.
> kolikrát z formátů typu JSON není patrné, jak záznam pojmenovat nebo to dokonce ani nemá rozumný název
Zrovna tady jsem kdysi zkoušel dělat analyzátor struktury JSONu (dostal příklad a vypadla z něj definice tříd) a nažvy tříd vymýšlel celkem dobře heuristicky. A pokud to zvládne stroj, člověk by s tím uz vůbec neměl nít problém.
> mnoha jazykům chybí anonymní a místo toho používají Either
Either mi přijde vpohodě, na Either3 a výš si radši napíšu abstract sealed class (ve Scale). Kdyby šlo takový typ definovat anonymně, stejně bych dřív nebo později většinou potřeboval typedef.
> Jména můžete vzít z proměnných
OK. U neveřejného API si to umím představit. U veřejného API bych stejně chtěl explicitní typovou anotaci (aby inferovaný typ nebyl příliš specifický, což by mohlo vadit při budoucích úpravách) a tam se tomu pak nevyhnu.
-
Radek Miček (neregistrovaný)
Tam typicky chci ten typ i pojmenovat, protože se bude předávat dál.
Mně přijde docela těžké vymyslet rozumné názvy pro takové množství typů - např. při dotazech do tabulky s uživateli mohu potřebovat názvy typů pro různé podmnožiny
{ id: int, realname: string, email: string, nickname: string, ... }- může to být klidně i 10-20 typů pro jednu tabulku. Ve skutečné aplikaci pak budou třeba i typy, kdy se joinovalo více různých tabulek.na Either3 a výš si radši napíšu abstract sealed class (ve Scale)
Nevýhodou tohoto přístupu je, že pokud máte funkce, kde jedna vrací např A/B/C, druhá B/C, třetí A/C, čtvrtá A/D a chcete napsat funkci, která umí zpracovat A/B/D, tak se to celkem těžko vyjadřuje (pokud to vůbec jde, musíte ve Scale zkonstruovat podivnou hierarchii). Tohle řeší třeba shapeless pomocí typu Coproduct, ale ten má zase jinou řadu nevýhod. Dotty již tohle zvládne díky union typům.
Další nevýhodou je, že musíte vymýšlet názvy pro ty typy - někdy to je dost těžké a skončí to názvem typu
NázevFunkceResult. -
ebik (neregistrovaný)
Vhodne udelany querybuilder muze generovat i typy, nebo naopak z typu generovat seznam sloupcu do selectu. Beztak chce mit clovek osetreno cteni z databaze, ze sloupec je spravneho typu, a pokud ne tak !unreachable() nebo !panic(). Ostatne cteni z databaze nebo zapis do databaze je specialnim pripadem serializace/deserializace. Pokud jazyk umoznuje obecnou serializaci/deserializaci napriklad pomoci introspekce, tak by v nem takovy querybuilder mel jit napsat. (Tohle jsem nedavno pachal v golangu.)
-
Tak napriklad Decko tuple zna a podporuje, a ano vetsinou jej vyuziva kde to ma smysl, ale i tak tam out ma sve misto, je to neco jako ref se specialni semantikou, krom toho ze tim clovek oznacuje referenci ktera ma znazornovat vystup a obcas se to muze hodit, tak zaroven rika ze je defaultni hodnota inicializovana dle typu.
-
Tak jeden z pripadu kdy se out hodi je pouziti UFCS.
auto funOut(out size_t length) {
length = "ahoj".length;
return "ahoj";
}size_t length;
auto res = funOut(length).someFun.anotherFun.andNextAnotherFun(length);pokud bych mel tuple tak bych musel udelat toto
auto tmp = funOut();
auto res = tmp[0].someFun.anotherFun.andNextAnotherFun(tmp[1]);Dalsi pripad uziti je kdyz potrebuji predat OutputRange, to se da predat sice referenci ale kdyz tam clovek zada to out tak ma jistotu ze v tom OutputRange nic nezbylo a hlavne to slovou out ma dokumentacni charakter ze clovek vi ze to je pouzito pro vystup, pokud by tam bylo ref, tak to muze a nemusi byt pouzito pro vystup.
-
Out parametry jsou imperativní styl. První příklad mi přijde špatně čitelný, není moc jasné, kdy se čte a kdy píše atd.
S tuples a pattern matchingem ten druhý příklad může vypadat nwjak takto:
auto (s, length) = funOut();
auto res = s.someFun.anotherFun.andNextAnotherFun(length);Což mi přijde mnohem srozumitelnější.
-
atarist (neregistrovaný)
Pozor na to, ze Rust ma taky 'ref', ale pouzivat se ma jen nekde:
https://internals.rust-lang.org/t/use-of-ref-must-in-let-statements/1466
-
lopata (neregistrovaný)
Je to z důvodu zjednodušení práce, Rust provádí automatickou dereferenci při volání funkce. Může to udělat, protože compiler má dostatek informací k tomu, aby takovou konverzi provedl automaticky: https://doc.rust-lang.org/book/deref-coercions.html
Podobná situace je i v C++ s operátory -> a . (tečka). I C++ compiler má dostatek informací k tomu, aby mohl automaticky konvertovat -> na . a opačně, ale neděláto to spíše z historických důvodů. Nicméně i v C++ by to šlo a mohl by existovat jen jeden operátor.
-
robotron (neregistrovaný)
Uspora 1 znaku je asi irelevantni, patrne je tedy jadrem: "nemusím přemýšlet, kolikrát ji mám napsat." Trochu se bojim, aby tato dusevni uspora nebyla vyvazena tim, ze to pak zlenivsi clovek nekde jinde pokazi (kde uz dvoji vyklad zapisu mozny bude). Treba se to v Rustu ale stat nemuze.
Kazdopadne dekuji za odpoved.
-
Obecně v C++ nelze automaticky konvertovat mezi . a ->. Např:
auto p = std::make_unique<std::unique_ptr<int>>(nullptr); std::cout << p.get() << std::endl; std::cout << p->get() << std::endl;
vypíše dvě různé hodnoty, protože p.get() volá metodu objektu p, ale p->get() volá metodu objektu *p, protože p->get() je totéž, jako p.get()->get() nebo (*p.get()).get().
Syntakticky shodné nebo vzájemně zaměnitelné a kompilátorem automagicky rozpoznané zápisy hodnot, referencí a ukazatelů mi přijdou spíš matoucí než užitečné.
-
lopata (neregistrovaný)
Tohle je taky historické dědictví, unique_ptr "chytře" využil toho, že existují dva různé operátory -> a tečka a chování -> přetížil, takže vlastně dělá něco úplně jiného, než normálně. Jestli je to dobře nebo špatně, to už nechám na posouzení každého soudruha.
Historie operátoru -> ale sahá až do roku 1975, kdy fungoval trochu jinak, než jako funguje v současném C. V tehdejším C bylo naprosto legální napsat tohle:
struct S { int a; /* 2 bytes, offset 0 */ int b; /* 2 bytes, offset 2 */ }; int i = 5; i->b = 42; /* Write 42 into `int` at address 7 */ 100->a = 0; /* Write 0 into `int` at address 100 */Tehdejší C vyžadovalo, aby položky všech struktur měly unikátní jména, takže položka struktury byl jen takový alias k offsetu adresy. Proto bylo možné napsat:
int i = 5; i->b = 42; /* Write 42 into `int` at address 7 */ 100->a = 0; /* Write 0 into `int` at address 100 */
Nebylo ale možné místo toho použít:
int i = 5; (*i).b = 42; /* Write 42 into `int` at address 7 */ (*100).a = 0; /* Write 0 into `int` at address 100 */
protože nelze dereferencovat integer. Bylo tedy nutné mít rozdílné operátory -> a (*). V moderním C(++) už nemá operátor -> smysl, jeho chování je ekvivalentní s (*). a compiler by mohl mít jen jeden operátor . a provést automatickou dereferenci pointeru, nicméně operátor -> v C zůstal.
Podrobně je to popsáno zde: http://stackoverflow.com/questions/13366083/why-does-the-arrow-operator-in-c-exist
-
atarist (neregistrovaný)
uff tedy popravde to byl peknej hnus, a to jsem si myslel, ze a[100] = 100[b] je to nejhorsi, na co lze v cecku narazit :)
Jinak kdyz jsme u toho, Placal to ma taky, akorat to pouziva jeste hur zapsany ^., to uz ta nase sipka -> je mnohem citelnejsi a vlastne graficky ukazuje, o co jde :)
-
Právě že v moderním C++, kde se dost používají chytré ukazatele, má -> dobrý smysl a není redundantní, minimálně do doby, než bude možné přetížit operátor tečka. To už nemá nic společného s chováním -> v prehistorické verzi jazyka C.
Abychom se vrátili od C++ k tématu tohoto seriálu, unique_ptr je ukázka toho, jak je v C++ možné prostředky jazyka definovat nové typy (zde chytré ukazatele), které syntakticky vypadají a sémanticky mají některé vlastnosti stejné jako vestavěné typy jazyka. Zároveň ale k vestavěným typům přidávají něco navíc. Mě by zajímalo, zda a jak efektivně je něco takového možné udělat v Rustu.
-
lopata (neregistrovaný)
Dva operátory tečka a -> v C++ se aktuálně (zne)užívají u smart pointerů dost, nicméně ono to má svoje úskalí, překladač nemůže kontrolovat chyby programátora, pokud v C++ napíšu:
if (unique_ptr_object.get())
if (unique_ptr_object->get())
tak obě konstrukce jsou naprosto v pořádku a přeloží se, každá ovšem dělá něco úplně jiného. Je velmi snadné splést se a překladač nemá žádnou možnost, jak chybu odhalit. Znovu opakuji, je to spíš z historických důvodů, C(++) dva operátory tečka a -> nepotřebuje, stačila by tečka.
V Rustu podobná chyba nemůže nastat, jazyk tomu přímo zabrání, protože obě konstrukce:
object.get();
(&object).get();
Dělají úplně to stejné, v Rustu se nejde splést.
Co se týká nových typů, tak Rust má traits a operator overloading:
https://doc.rust-lang.org/book/traits.html
https://doc.rust-lang.org/book/operators-and-overloading.html -
To, že dvě různé konstrukce p.f() a p->f() dělají každá něco jiného, není až tak překvapivé. Ano, programátor se může splést. Ale podobně se může splést a napsat a + b místo a - b. Celá tohle dohadování se, kde je a není snadné se splést, je založeno na osobních preferencích a má sice velký potenciál rozpoutat flamewar, ale těžko povede k nějakému rozumnému závěru.
Ve druhé části jsem se ptal na něco trochu jiného. Např. v C++ můžu vyrobit typ checked_int, který bude vypadat a chovat se stejně, jako nativní int, ale u aritmetických operací bude vyhazovat výjimku při přetečení nebo dělení nulou. Jde něco podobného udělat v Rustu tak, aby přidaný typ zapadl do jazyka tak, že se při jeho použití nebudu muset uchylovat k nějakým speciálním syntaktickým konstrukcím a nevznikne nějaká neefektivita, např. skryté alokace paměti?
-
Jvr (neregistrovaný)
Ano přesně toto mi přijde tak trochu zvláštní. Jakmile totiž začnete něco řešit "v tom případě má překladač dost informací" (není tam potřeba derefernci psát)... apod. začíná z toho být trochu zmatek. Já nejsem překladač abych poznal kdy on už má dost informací a kdy ne a navíc ten člověk, co se ten kód po mě (možná) někdy v budoucnu bude snažit přeluštit, taky není překladač a právě tam vzniká nevíce chyb (úprava jiným programátorem).
A teď babo raď: "iter1.filter(|x| even(*x));" je tam skutečně potřeba ta hvězdička? Pokud ne je idiomaticky správné ji tam psát nebo nepsat?
