00:29:56  <Domenic>This whole identifier vs. expression vs. destructuring syntax business is a rough problem
00:30:04  <Domenic>Very curious if there's an elegant solution hiding somewhere
00:30:08  <Domenic>It seems key
00:31:24  <samth>Domenic: note that the destructuring syntax follows conventional pattern matching; ie that `match 1 { x : x }` produces 1
00:31:35  <samth>and I agree that it's key
01:05:10  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
02:07:09  <Havvy>I do find it weird that an identifier in the match syntax is a custom matcher instead of binding an identifier. But then, you want to also have custom matchers give custom destructuring a. la. regexp?
03:23:25  * AtumTquit (Remote host closed the connection)
04:02:23  * jmdyckquit (Quit: Leaving.)
05:18:21  <Bakkot>Digging through my dad's stuff, I found some old docs from TC39 circa '99.
05:18:46  <Bakkot>Including e.g. what may be the earliest coherent classes proposal, from Herman Venter of Microsoft.
05:19:18  <Bakkot>It's funny; it gives a few sentences to private fields, and pretty much assumes they'll be easy because we'll have type annotations.
05:19:21  <Bakkot>Not so much.
05:41:56  <ljharb>Bakkot: your dad was on tc39?
05:46:49  <Bakkot>ljharb: indeed yes
05:46:59  <Bakkot>he's credited in ES3, in fact.
05:47:38  <Bakkot>http://www-archive.mozilla.org/js/language/E262-3.pdf "The following people have contributed to the work leading to ECMA 262: [...] Bill Gibbons"
05:52:08  <Bakkot>littledan, wycats, jeffmo etc: I am increasingly uncomfortable with the shorthand syntax for access private properties and would prefer to see it removed before stage 3.
05:52:31  <Bakkot>My concern can be summed up as "property access without an explicit receiver is (/ feels like) an antipattern in programming language design".
05:52:44  <Bakkot>In particular, there's at least two potentially confusing parts:
05:53:15  <Bakkot>1) In `class A { #x = 0; y = 1; m() { #x++; y--; } }`, the increment affects an instance field, and the decrement affects a closed-over variable (and not the instance property of the same name). Even if that's intentional, those things should _not_ look so similar.
05:53:42  <Bakkot>2) The confusion about the receiver when invoking private methods: in `class A { #m() { return this; } a() { #m() } }; (new A).a()`, the fact that the call to `#m` returns the instance is not at all obvious from the code.
05:54:40  * afraeljoined
05:54:44  <wycats>1. I disagree with your arguments.
05:54:44  <wycats>2. I don't think I'm going to win this one and don't want to be responsible for blocking private state over what many people seem to believe is a quixotic quest, so I'll probably give in before long
05:55:44  <Bakkot>My impression has actually been that most people are on board with the shorthand syntax, and I was trying to figure out if I felt strongly enough to block it
05:56:03  <Bakkot>I feel like I don't understand the arguments for the inclusion of the syntax very well, though, and would like to.
05:56:10  <wycats>A handful of people share that perspective, and that doesn't bode well for "sugar"
05:56:55  <wycats>Re: 1, my disagreement stems from the fact that I believe that private state is a significant new feature, and what is perceived as "obvious" will, in some sense, be driven by usage and idioms
05:57:17  <wycats>I strongly disagree with the "antipattern" point, but I suspect you didn't mean it quite as strongly as that
05:57:25  <wycats>Private methods affect my calculus some
05:57:48  <wycats>It's almost 11pm here, perhaps we could schedule a VC in the near future (perhaps littledan would like to join)
05:58:25  <wycats>(they affect my calculus in your direction, to be clear)
05:58:39  <Bakkot>sure; let's coordinate that tomorrow? I am also on PST, but littledan was not last I checked.
06:03:59  <wycats>Yep
06:04:06  <wycats>Ping me tomorrow :)
06:04:15  <wycats>New baby means I try to stick to work hours when I can
06:04:20  <Bakkot>
06:05:06  <wycats>I'd generally feel better if I knew you understood the arguments and came away unpersuaded :)
06:05:20  <Bakkot>Me too!
06:06:10  <Bakkot>I really don't want to say "I don't know why this is here, but let's remove it".
06:07:05  <Bakkot>(even though I just did.)
06:20:12  * gskachkovquit (Quit: gskachkov)
06:20:25  * gskachkovjoined
06:25:04  * gskachkovquit (Ping timeout: 260 seconds)
06:43:45  <littledan>I work in European time, but don't have a baby and am fine to meet any time until 3 PM PST
06:55:49  <littledan>Bakkot: diervo and I were also talking about the commas, which are causing some confusion among the people who are working on implementation in Babel and writing tests, e.g., https://github.com/babel/babylon/pull/608#issuecomment-312627433
06:56:45  <Bakkot>Oh jeeze, I didn't realize there was Typescript precedent which differed.
06:58:15  <Bakkot>I get the rational for comma declarations for use decorators, though, and expect that people would be more surprised by TS's behavior than the proposed behavior here.
06:58:45  <Bakkot>(I wouldn't object to making commas a part of the decorators proposal, mind, but that might be too weird a separation.)
06:59:59  <Bakkot>I wonder if we could talk to TS users and/or developers about that difference?
07:00:19  <Bakkot>TS decorators are marked as 'experimental' pretty vividly, looks like, which is good.
08:33:31  <littledan>I don't know if marking them as experimental is that strong of a signal; the sigil debate made it clear that people depend strongly on decorators being roughly how they are on the user end (even if it's fine for library authors to need to change things)
09:17:18  * gskachkovjoined
09:25:20  * gskachkovquit (Ping timeout: 255 seconds)
10:25:12  * mylesborinsquit (Quit: farewell for now)
10:25:42  * mylesborinsjoined
10:39:19  * jmdyckjoined
12:19:04  * gibson042quit (Quit: Leaving.)
13:17:58  * bradleymeckjoined
13:37:59  <Domenic>+1 Bakkot, although not strong enough support to engage in long discussions or block or anything. I just agree I'd much prefer explicitness.
14:15:39  <bradleymeck>without explicitness, could #global mean something eventually? a thing that is pulled off global scope?
15:15:57  * caridy_joined
15:18:57  * caridyquit (Ping timeout: 248 seconds)
15:29:50  * caridyjoined
15:29:50  * caridy_quit (Read error: Connection reset by peer)
15:51:10  * gskachkovjoined
15:55:45  * gskachkovquit (Ping timeout: 248 seconds)
16:05:40  <littledan>bterlson: Any idea when we'll get pipeline on the agenda?
16:07:12  <bterlson>littledan: working on it after pattern matching dies down a bit :-P
16:08:01  <bterlson>btw the tweet I sent about it is at 51k impressions, by far the most I've gotten. I guess it's an exciting feature even if it's not clear what it'll look like.
16:08:04  <littledan>bterlson: yay!
16:16:13  <bterlson>oh my god so many comments
16:16:20  <bterlson>maybe I should do pipeline now
16:16:24  <bterlson>:-P
16:18:14  <littledan>pipeline is way easier
16:19:34  <bterlson>littledan: the difficulty will be answering the extensive "why not bind" questions
16:19:57  <bterlson>I have to write up a fair amount of text on that topic
16:20:43  <littledan>is there anything to say about, why do this with the first argument (as opposed to, e.g., the receiver or the last argument)?
16:32:48  <Bakkot>"that's the idiom in functional style / mathematics", is I think the reason, no?
16:34:21  <bterlson>littledan: with the proposed syntax for partial application it becomes less important
16:34:35  <bterlson>x |> foo(?, 10) |> bar(10, ?)
16:37:39  <bradleymeck>getArgs |> call(...?)
16:37:47  <bradleymeck>would be somewhat interesting
16:40:36  <bterlson>indeed
16:40:46  <bterlson>I feel so good about this proposal in part because I keep discovering useful things
16:41:11  <bterlson>like Ron recently discovered that you could do this-style pipeline via call/apply: [1,2,3] |> Array.prototype.map.call(?, x => x * 2)
17:29:57  <Bakkot>bterlson: [1,2,3] |> ?.map(x => x * 2)
17:30:28  <bterlson>Bakkot: I had that in early proposals but the special form seemed unnecessary and potentially confusiong
17:30:39  <Bakkot>hmmmm
17:31:15  <bterlson>is map looked up as an identifier or as a property of the LHS object?
17:31:32  <Bakkot>property, obviously
17:31:33  <bterlson>looks like the latter but the former is the predominant use case I think
17:31:37  <Bakkot>. always is property
17:31:42  <ljharb>[1,2,3] |> ::Array.prototype.map(x => x * 2)
17:31:44  <bterlson>unless it has another dot above it :-P
17:31:52  <ljharb>ah no that wouldn't work
17:35:06  * AtumTjoined
17:35:24  <Bakkot>bterlson: not convinced former is predominant use case
17:35:30  <Bakkot>or, especially, will be going forward
17:36:30  <bterlson>Bakkot: yeah could be right
17:36:41  <Bakkot>it isn't all that common to have functions which operate on their 'this' and don't expect 'this' to be something with the function as a property of it
17:36:56  <Bakkot>i.e. functions which are expected to be used via .call etc
17:37:13  <Bakkot>is my impression, anyway.
17:38:12  <bterlson>if we get extension methods or "interfaces" ala @jspedant's interface then I can see this happening much more
17:38:28  <bterlson>Bakkot: isn't that an argument against the :: operator with the exception of its method extraction tool?
17:39:18  <Bakkot>kinda! but :: is good for postfix calls, which is something a lot of people want, so if we got :: we'd start seeing more of those functions.
17:43:22  <Bakkot>the interfaces proposal actually does add methods to the prototype, so it would work with a |> ?.foo
17:43:54  <Bakkot>incidentally, I found a postfix / infix proposal from '99
17:44:12  <bterlson>Bakkot: yeah that's what I'm saying, interfaces or extension methods or similar might argue for ?.blah syntax
17:44:19  <Bakkot>ahh, yeah
17:44:23  <bterlson>I also argue that these are the proposals that :: proponents mostly want :-P
17:44:43  <bterlson>with the exception of method extraction which I want bad but unsure if prefix :: is the right syntax for it
17:44:47  <Bakkot>:: is so much prettier than |> ...
17:44:53  <bterlson>disagree!
17:45:02  <bterlson>in a monospaced font |> is more palatable at least
17:45:10  <bterlson>plus, aren't you using ligatures and a programming font? ;)
17:45:21  <bradleymeck>gah
17:45:22  <bradleymeck>never
17:45:25  <bterlson>lol
17:45:58  <bradleymeck>the real programming font I want is one that shows me ASI semicolons, even if they don't go to disk
17:46:56  <bterlson>hmm
17:46:58  <Bakkot>bradleymeck: prettier/eslint on save
17:47:09  <bradleymeck>Bakkot: i've done that, but it janks things
17:48:03  * bradleymeckquit (Quit: bradleymeck)
17:59:27  * AtumTquit (Ping timeout: 240 seconds)
18:11:50  * AtumTjoined
18:16:38  <ljharb>|> is super ugly :-/
18:16:44  <ljharb>→ would be nice tho :-p
18:26:04  * bradleymeckjoined
18:26:17  <Domenic>bterlson: we are closing in on a final version of the modules spec patch. In fact we think what's up now is good. But we might want to refactor a bit later. Can we land now and refactor, or do you think we should do it all at once?
18:26:37  <Domenic>My main concern is right now everyone has to implement off of PRs instead of master, so I would rather land things sooner
18:27:51  <bterlson>Domenic: how big is the refactor?
18:28:19  <bterlson>Domenic: don't want to merge something that will be completely rewritten. Maybe an editor note with a link to the WIP?
18:29:27  <Domenic>bterlson: It looks like the current refactor proposal is to go from ResolveExport(x, y, paramToControlBehavior) returning x to ResolveExport(x, y) returning {x, infoAboutBehaviorYouShouldAlsoDo} and then move that behavior out to one of its callers.
18:29:52  <Domenic>So, IMO pretty local
18:31:56  <bterlson>I haven't read the proposal recently, but what's the holdup on doing that refactor?
18:32:31  <Domenic>It just takes time, and we're not sure it's even a better refactor; we're debating it among three people in different timezones.
18:33:11  <bterlson>alright, I'll leave it up to you then
18:33:24  <Domenic>Sounds good. I'll CC you on the thread.
18:33:30  <bterlson>thanks
18:33:39  <bterlson>unsure what the consensus status is also
18:33:47  <Domenic>We got consensus last meeting!!
18:33:53  <Domenic>This I am very sure of
18:34:10  <Domenic>It was pretty blanket too, especially with regard to refactorings and ways of meeting the overall goal we got consensus on
18:35:15  <bterlson>that was my recollection as well
18:35:24  <bterlson>plus, few people seemingly engaged in the room
18:39:49  <bterlson>Domenic: is there a list of normative changes? Is the OP still up to date?
18:41:19  <Domenic>bterlson: pretty much, yeah.
18:41:33  <Domenic>The change in ResolveExport()'s signature might count as normative?
18:51:12  * bradleymeckquit (Quit: bradleymeck)
18:56:14  * bradleymeckjoined
19:11:06  <Domenic>bterlson: did you forget to push the "send review" button? I don't see any comments
19:11:57  <bterlson>Domenic: I did, thanks :)
19:50:58  * gskachkovjoined
20:29:05  * afraelquit (Remote host closed the connection)
20:29:40  * afraeljoined
20:33:45  * afraelquit (Ping timeout: 240 seconds)
22:38:49  * bradleymeckquit (Quit: bradleymeck)