Varbūt esmu nedaudz lēns, bet String implementācija Swift izpratnē ir kaut kas bezbožna idiotisks. Abstrakcija un objektu/stuktūru modelis tāds, ka Java nobāl. Nu, nopietni. Ieviest string[startIndex...endIndex], bet neļaut tur izmantot Int?
@laacz tvītu arhīvs
Sakarā ar to, ka Twitter ir slēdzis bezmaksas piekļuves savam API, šis projekts var tikt uzskatīts par mirušu sākot ar 2023. gada 15. jūniju.
Šis ir tvitera pavediens. No senākā uz svaigāko. Tvītu skaits: 32
@laacz Izskatās dīvaini, tā ir standarta liba implementācija? String.index rezultāts ir ne Int tips? Drošivien typesafety-ijs, lai gan tad ieguvums minimāls, substrings nefeilos, index feilos 😒
@laacz Es, protams, no tā visa maz ko saprotu, taču man šķiet, ka 1) tas ko es redzu ir funkcijas substring implemantācija. 2) startindex, endindex iespējams arī ir int, bet iespējams tikai pozitīvi skaitļi 3) pieļauju, ka self.index "dīlo" ar ārpuslimita (piem. negatīviem) skaitļiem.
@Kolliss Tā ir substring implementācija, jo katru reizi šo visu rakstīt, kad vajag substring, negribās :)
@_ingars Nē, standartā viņiem nemaz substring nav. Tā ir userspace implementācija.
@laacz Ok, tagad sāk pielekt par ko tu vispār runā. Varu tikai izteikt cerību, ka šī "nebagātā" pieeja vismaz nodrošina izcilu performanci. :) Bet nu zini kā, chara garums jau arī ne vienmēr ir tieši baits, tāpēc jāizrēķina precīzi, līdz kurienei jāgrābj :)
@Kolliss @laacz https://developer.apple.com/documentation/swift/string/index kaut kas par to, ka unicode stringiem tu nevari tā vienkārši paņemt i-to burtu, jo to, ko tas nozīmē var interpretēt dažādi
@ramuuns @Kolliss Visi var, Swift nevar? :) tīrs unicode ir sen atrisināts jautājums.
@laacz @Kolliss Es pieņemu, ka tur vaina ir Objective C interoperability, kurš nu principā ir C ar dīvainu sintaksi, līdz ar to, lai tas normāli darbotos ir vajadzīgas šīs papildus datu struktūras, kuras tad arī izlien ārā dažādos brīžos
@ramuuns @Kolliss Nu. Pēc objective c swift ar savu highly opinionated un weird piegājienu tomēr ir Ok :)
@laacz @Kolliss Paskatoties citas modernas low-level valodas (piem rust https://doc.rust-lang.org/std/string/struct.String.html), tur ar stringiem arī ir samērā komplicēti.
@laacz @Kolliss Es gan teiktu, ka vaina tajā, ka mēs uzaugām ar "strings ir charu masīvs", bet tā lieta (īpaši unicode gadījumā) ir īstenībā sarežģītāka un pie tā vienkārši jāpierod
@Kolliss @laacz Dažādi mērķi un pielietojumi ;) Bet perlā man ļoti patīk darboties ar tekstu
@ramuuns @Kolliss Tas gan. Performance implikācijas ir mega.
@laacz Easy, bet ne swiftā.
@mareksm Tas nebūs full unicode :)
@laacz @_ingars Tīri ziņkārībās pēc, vai Swift ir daudz tādu metožu, kam pēc būtības būtu jābūt pieejamām standartā, lai developeriem nebūtu no jauna jāizgudro divritenis?
@ViktorsTelle @_ingars Savā ziņā šis ierobežojums ir saprotams, bet tad, kad zini, ka strings nav random unikode ar modifikatoriem un citiem brīnumiem, šis kaitina.
@laacz Aizstāj wchar_t ar char32_t, nomaini lokāli uz kādu "platāku" un aidā.
@laacz Vēl viena fiška swiftā kas noteikti patiks ir šī: "The ++ and -- operators have been deprecated"
@mareksm Tas pats UTF-8 var saturēt arī sešus baitus garus codepointus :)
@mareksm Atteikšanās no preincrement un postincrement ir modē. Arī Rustā nav ;)
@laacz @ViktorsTelle Ir ir saprotams, vienkārši pierasts, ka strings ir “parasts” strings un tad ir speciāls unikodes strings. Unikodes strings “by default” makes sense, imo.
@_ingars @ViktorsTelle Aha. Tik jāpierod. Un jāsagaida hardware accelerated string operations :P
@laacz Tā nu tas ir, šeit par to vairāk runā no valodas perspektīvas https://docs.swift.org/swift-book/LanguageGuide/StringsAndCharacters.html#ID494 Tas ir blakusefekts savienojot Unicode scalars. No sākuma man šķiet arī dīvaini, bet laikam pieradu.
@fassko @laacz Neesmu nekad ar Swift darbojies, bet vai teorētiski nebija iespējams uztaisīt, ka greeting[7] automātiski interpretējas kā greeting[greeting.index(greeting.startIndex, offsetBy: 7)]?
@kaitnieks @fassko Teorētiski jā, ja mēs uzskatām, ka lietotājs tiešām grib codepointu, nevis baitu :P