| 04:53 | <jschoi> | https://github.com/tc39/proposal-pipeline-operator/issues/232#issuecomment-990615800 |
| 04:53 | <jschoi> | https://github.com/tc39/proposal-pipeline-operator/issues/91#issuecomment-990614661 |
| 15:51 | <jschoi> | https://github.com/tc39/proposal-pipeline-operator/issues/91#issuecomment-991010158 raised the point that the only thing keeping # from being the topic token is record/tuple literals being #{} and #[] and not {||} and [||]. And this question still doesn’t seem to be settled, since tc39/proposal-record-tuple#10 hasn’t seen recent activity and the most recent record/tuple update from October did not mention the spelling issue. |
| 15:51 | <jschoi> | nicolo-ribaudo: Has there been recent talk over whether the record/tuple champions are committed to #{} and #[] and not {||} and [||]? Is there still any chance of the latter syntax being what you choose? |
| 20:02 | <James DiGioia (mAAdhaTTah on GH)> | Honestly, I rather like {| |}. I think Flow uses that syntax as well. |
| 20:06 | <rbuckton> | That could be a reason they can't or won't adopt it however. |
| 20:09 | <jschoi> | Whether or not Flow or other JS dialects impose hard constraints on record/tuple literals’ spelling, we probably should wait on committing to wholly rejecting # as a topic token until the record/tuple champions commit to #{} and #[] (or {||} and [||]). |
| 20:38 | <TabAtkins> | I'm fine with holding onto # as an explicit stretch goal |
| 20:39 | <James DiGioia (mAAdhaTTah on GH)> | That could be a reason they can't or won't adopt it however. |
| 20:39 | <James DiGioia (mAAdhaTTah on GH)> | Which actually could be conflicting, now that I think about it, cuz it's not about immutability but extra properties. |
| 20:42 | <pokute> | Which actually could be conflicting, now that I think about it, cuz it's not about immutability but extra properties. const foo: {| a: 2 |} = { a: 2 } then? |
| 20:44 | <Ashley Claymore> | The flow conflict would be that the type would look like a record literal but be an object type. So could be confusing. But wouldn’t be a technical clash |
| 20:44 | <Ashley Claymore> | computers would understand the difference |
| 20:45 | <pokute> | The only point that it conflicts is that with const foo: {| a: 2 |} = { a: 2 }; flow will not be able to declare a tuple type as easily. |
| 20:46 | <James DiGioia (mAAdhaTTah on GH)> | The flow conflict would be that the type would look like a record literal but be an object type. So could be confusing. But wouldn’t be a technical clash |
| 20:47 | <pokute> | Heh, I meant a record. |
| 20:47 | <James DiGioia (mAAdhaTTah on GH)> | Oh right yeah |
| 20:47 | <James DiGioia (mAAdhaTTah on GH)> | Well, computer wouldn't know the difference between "Exact Object Type" & "Record Type" |
| 20:48 | <James DiGioia (mAAdhaTTah on GH)> | Unless Flow came up with a distinct syntax for Record Types |
| 20:52 | <pokute> | Actually, Tuple typing at all in JS IS interesting. For typing the only real issue I think is when something returns a tuple/record. Further, typescript has already a more intricate support for everything except an ergonomic syntax for it. I think there's even DeepReadonlyObject<T> generic (though not included in standard TypeScript typing definitions) |
| 20:52 | <jschoi> | As far as I know, TC39 has never considered TypeScript, Flow, etc. to be hard blockers on potential new future ES syntax, and TypeScript has done backwards-compatibility changes to accommodate new ES syntaxes. |
| 20:52 | <TabAtkins> | yeah, we do soft avoidance of clashes, for politeness' sake, but that's it |
| 20:53 | <jschoi> | TypeScript and Flow have the luxury of language versioning, haw. |
| 20:54 | <pokute> | TypeScript can break stuff between minor versions (since the versioning is 2.9 -> 3.0). |
| 20:54 | <pokute> | And a new TS version is released every 2 months IIRC. |
| 20:56 | <pokute> | I believe that Flow and TS would really really want an ergonomic type to define tuples and records. Preferably the same syntax as in JS. |
| 20:56 | <Ashley Claymore> | Flow is also moving for types to be closed by default |
| 20:57 | <Ashley Claymore> | so the {| |} flow type syntax is actually semi deprecated |
| 20:57 | <pokute> | For Flow, it seems like it would be a breaking change to change {| |} behaviour, but it should be pretty easy to fix through something like codefix. |
| 20:57 | <Ashley Claymore> | That said I don't think the reason R&T was not using that syntax was because of the clash with Flow. |
| 20:58 | <pokute> | {| |} has the disadvantage that it's not as ergonomic to change objects -> records and vice-versa since you have two places to edit. |
| 21:01 | <jschoi> | That said I don't think the reason R&T was not using that syntax was because of the clash with Flow. |
| 21:02 | <Ashley Claymore> | See also https://github.com/tc39/proposal-record-tuple/issues/10. |
| 21:02 | <Ashley Claymore> | my colleagues are the champions, so I take an active interest :) |
| 21:06 | <pokute> | Though, it feels like flow's {| a: string |} is for a use case that feels extremely rare: for const foo: {| a: string |} = { a: 'a', b: 1 }; // Error. Maybe someone could scour existing flow projects for them. |
| 21:07 | <pokute> | Wasn't Flow mainly used at Facebook? maybe we can ask for someone who has access to their repo. |
| 21:11 | <Ashley Claymore> | As I said earlier, flow is moving towards 'exact types by default' https://medium.com/flow-type/on-the-roadmap-exact-objects-by-default-16b72933c5cf |
| 21:11 | <Ashley Claymore> | so {| a: string |} in Flow can be replaced with { a: string }and you opt-out of it with { a: string, ... } |
| 21:22 | <ljharb> | why does it matter if flow conflicts? flow isn't js. |
| 21:22 | <ljharb> | that's just the risk things take when they extend JS syntax in any but the one way reserved for that purpose (the altho in this case it's flow's type syntax, so JS having that syntax in a value context wouldn't even conflict in a technical sense, just a conceptual one. |
| 21:23 | <pokute> | As I said earlier, flow is moving towards 'exact types by default' |
| 21:24 | <ljharb> | ¯\_(ツ)_/¯ in react propTypes, using exact types has caught innumerable bugs, including typos on optional prop names, so i think there's tons of value in that being the default in a type system. |
| 21:26 | <Ashley Claymore> |
|
| 21:33 | <jschoi> | I'm fine with holding onto # back to the table of candidates in https://github.com/tc39/proposal-pipeline-operator/wiki/Bikeshedding-the-Hack-topic-token/. |
| 21:38 | <pokute> | After having followed many different ECMAScript proposals, is there a FAQ counterargument against the "syntax soup" -argument that is pretty common? Basically explaining that we don't even need ECMAScript 3 to tailor unreadable code. |
| 21:39 | <jschoi> | Argument soup? You mean ASCII soup? |
| 21:46 | <pokute> | As in I don't think people should care about readability of code that hasn't had any readability in mind when it was written. |
| 21:47 | <TabAtkins> | There isn't a counter-argument; it's a valid argument. |
| 21:47 | <TabAtkins> | Perl is an existence proof of what JS should not become in regular usage. How quickly we get there is individually arguable, but we all agree it's a bad endpoint, and every new syntax addition pushes us there. |
| 21:48 | <jschoi> | Yes. Any new proposal has to be compelling enough to override the fact that any new feature adds more weight to the language. See https://erights.medium.com/the-tragedy-of-the-common-lisp-why-large-languages-explode-4e83096239b9 |
| 21:49 | <jschoi> | Many of us happen to believe that the benefits of the pipe operator outweighs its cost, but there is no denying that there is at least some cost. |
| 21:49 | <jschoi> | Same goes for any proposal. |
| 21:51 | <pokute> | My point was mostly the most recent ^^^ -example. When people don't bother adding a space, they haven't written the code with an intention of having it simple to read. |
| 21:51 | <jschoi> | I’ve seen a counterargument from Rob Palmer though against “you can sometimes create unreadable code with this”. His counterargument is that any reasonably powerful language feature can create difficult-to-read code. Like [[[], [[], [], [[]], []], [[]]]. |
| 21:53 | <pokute> | So I would rather focus on cases where making a easily readable version is cumbersome to write. |
| 21:58 | <pokute> | So in my opinion, less weight should be put on "most complex syntax soup I could write", some weight for "I naturally wrote this code and after I wrote it, I realized that it needed clarification" and most for "Writing this often occurring operation is pain to write clearly." |
| 22:05 | <pokute> | In comparison, balancing a dozen parenthesis for multiple nested function calls (which is not a rare to end up with) in my mind is vastly more difficult than almost any realistic usage of any suggested topic placeholder topic. |
| 22:13 | <TabAtkins> | Yes, that's more or less how we respond to such an argument. |