TC39 Delegates
2023-12-01
plaintext logs
prev next
source on github
00:19
<Michael Ficarra>
reviewing the notes is like reliving trauma
00:19
<Michael Ficarra>
this is inhumane
00:20
<ljharb>
 * ok, but reducing human use cases to percentages seems not very kind, either way :-) (i'm still convinced it's many more use cases than that considering most use cases i've run into is "a specific time" instead of "a repeating time where the precise time isn't super important")
00:38
<rkirsling>
is 2.7 meant as Math.ceil(2.62 * 10) / 10
00:49
<rkirsling>
oh right Math.floor(Math.E)
00:51
<rkirsling>
did no one even mention 2.62 this time though? geez, I'm hurt
00:51
<Chris de Almeida>
Math.round(Math.E * 10) / 10
00:52
<Chris de Almeida>
but no, the reality was far less clever
00:52
<Chris de Almeida>
USA:  CDA says, split the difference.  2.7.  Perhaps we have an option C.  

CDA:  Yeah.  Would the people who prefer 2.9 be happier with 2.7 rather than 2.5?  And same question reversed: for the 2.5 supporters, is 2.7 better than 2.9? 

WH:  Let’s just do 3 temperature checks.  One temperature check each of the three options.
00:53
<rkirsling>
Math.round(Math.E * 10) / 10
er yeah, dropped the 10s for some reason; coffee has not adequately entered my system yet
00:54
<Kris Kowal>
So…who’s going to register naturallog.es and start blogging proposal advancement?
00:55
<rkirsling>
I mean, if it's 2.7 then I think rounding is going to have to be the go-to explanation, as opposed to "so some people wanted 2.5 and some people wanted 2.9..."
00:56
<rkirsling>
but yeah I'm just shocked that 2.62 didn't even stick in a single person's mind enough to say it out loud :(
00:56
<Kris Kowal>
It’s less embarrassing. I say run with it.
00:56
<Chris de Almeida>
...porque no los dos...
00:58
<Chris de Almeida>
It’s less embarrassing. I say run with it.
I think it's great ackchyually -- the folks who wanted, literally, e, kind of got it 🙂
01:52
<rkirsling>
I guess I'll probably still describe it to people this way because it's literally a stage for test262
06:42
<eemeli>
Asking seriously: Could we at the next meeting ask for consensus on renaming the stage to 2.62, because that is a really good number. As in, if it had been on the table, I never would've even mentioned e.
06:44
<eemeli>
I mean, 2.7 is fine (it's e with an ε of under 0.7%, after all), but unlike the choices we actually talked about 2.62 isn't arbitrary.
07:53
<rkirsling>
I made a point of saying it formally in the last meeting: https://github.com/tc39/notes/blob/df1449925841bc77574e8e127611234670275575/meetings/2023-09/september-28.md?plain=1#L1287
14:52
<Chris de Almeida>
counterpoint: overloading 262 / 2.62 to refer to different things will lead to confusion
16:20
<ljharb>
additional counterpoint: repainting a thoroughly painted bikeshed is fun for some, but soul-crushing for others
16:59
<eemeli>
2.62 is something that I'd only present if it really did feel like it could be accepted pretty much unanimously.
17:21
<ethanarrowood>

Has anyone proposed adding a String.reverse() in the past? Basically what string.split("").reverse().join("") does?

I tried searching the proposals repo and can't find it but not sure if maybe its somewhere else

17:29
<ethanarrowood>
(And I guess if it hasn't been proposed previously then I know what my first proposal shall be 🚀)
17:35
<bakkot>
ethanarrowood: I think having a static String.reverse which is fundamentally different from String.prototype.reverse would be bad, but you could explore other designs
17:35
<bakkot>
e.g. a prototype reverseByCodePoints method, or a second argument to reverse
17:36
<bakkot>
that said reversing strings by code points is almost never an actually useful operation (see: combining characters, flag characters, etc), so I think you'd need a very strong motivation
17:36
<ethanarrowood>
Ahh I meant the later String.prototype.reverse
17:37
<bakkot>
Ohh I misread you, and assumed String.prototype.reverse already existed
17:37
<bakkot>
ok cool. well, I am glad it doesn't per above
17:37
<ethanarrowood>
Yeah I assumed it existed too, but found out it doesn't!
17:38
<nicolo-ribaudo>
It feels like something that could live on Intl together with Collator
17:39
<bakkot>
Does CLDR define how to reverse a string? I don't think so?
17:39
<bakkot>
I mean I guess you could do grapheme segmentation and then reverse that and then join, but I'm not sure that's ever useful
17:40
<bakkot>
More useful than reversing by codepoints, though, I guess
17:42
<ethanarrowood>
I see now why strings are better in languages like Rust. Takes some of this complexity away
17:44
<Ashley Claymore>
https://es.discourse.group/t/string-reverse-method/620/7
17:45
<Ashley Claymore>
(short convo there)
17:47
<bakkot>
Rust strings enforce utf8, which is certainly nice in some ways
17:47
<ethanarrowood>
Yep
17:47
<bakkot>
though I would say that most of the complexity relevant to what it means to "reverse" a string is inherent to unicode, and/or to written language
17:48
<ethanarrowood>
Okay cool so this maybe could exist on String.prototype it would just need to be a very smart algorithm to support complex inputs. Otherwise, it may have to exist on another construct
17:54
<bakkot>
It's not exactly that it needs to be smart, it's that the programmer needs to specify what they mean by "reverse"
17:54
<bakkot>
like, what is the correct output when you "reverse" "🇺🇸"?
17:55
<ethanarrowood>
My assumption would be "🇺🇸"
18:02
<bakkot>
so you want grapheme clusters, presumably, which means that yeah it would need to live in Intl
18:04
<bakkot>
though also I am not sure why you would ever want this
19:24
<rbuckton>
String.prototype.reverse({ by }) where by can be "char-code" or "code-point", and Intl can amend this to add "grapheme-cluster" or something? Much like String.prototype.localeCompare is extended/replaced by Intl?
21:29
<ethanarrowood>
Love that idea rbuckton and maybe it could also default to a "common case"