00:09:22  * JaseWquit (Quit: Leaving)
00:16:05  * bradleymeckquit (Quit: bradleymeck)
00:32:14  * srl295joined
00:51:50  * arai__joined
00:52:02  * arai__quit (Remote host closed the connection)
00:55:52  * araiquit (Ping timeout: 260 seconds)
01:27:10  * AtumTquit (Remote host closed the connection)
01:54:36  * araijoined
02:41:23  * srl295quit (Quit: Connection closed for inactivity)
02:51:54  * bradleymeckjoined
04:21:56  * bradleymeckquit (Quit: bradleymeck)
04:28:45  * bradleymeckjoined
05:07:37  * jmdyck1quit (Quit: Leaving.)
05:39:02  * bradleymeckquit (Quit: bradleymeck)
06:12:35  <devsnek>has anyone ever brought up Symbol.thenable or something similar
06:14:57  <devsnek>and maybe module namespace objects having Symbol.thenable on them :s
07:00:43  * araiquit (Remote host closed the connection)
07:17:21  <annevk>devsnek: that was discussed, but the protocol for thenables is having a .then property
07:48:01  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
08:21:05  * araijoined
10:25:07  * mylesborinsquit (Quit: farewell for now)
10:25:38  * mylesborinsjoined
11:44:00  <devsnek>annevk: yea but that doesn't really line up with the existence of isConcatSpreadable and unscopables
11:44:33  <devsnek>and hasInstance
11:48:42  <devsnek>if you add some symbols to modify language behavior you can't just bar others by that same reason
11:58:37  * annevkshrugs
12:42:40  <TabAtkins>devsnek: Yeah, thenables ended up being a nasty legacy hack, so shrug.
12:51:04  <devsnek>I just threw this together: https://github.com/devsnek/proposal-symbol-thenable
12:51:16  <devsnek>behaviour seems sane enough
12:53:23  <devsnek>i need to do a better job with the spec formatting though
12:54:26  * bradleymeckjoined
13:07:13  <devsnek>does anyone know how i can fix this weird formatting issue https://github.com/devsnek/proposal-symbol-thenable/blob/master/spec.html#L222 https://gc.gy/Ƅȋ❏.png
13:07:35  <devsnek>3.1 and 3.2 should be like indented and smaller right
13:15:32  * AtumTjoined
13:25:43  <caitp>are there use-cases for toggling an object's thenable-ness dynamically?
13:27:10  <caitp>or, disabling the thenable-ness of a prototypically inherited object's `then` method without replacing the `then` method
13:27:17  <devsnek>at least dynamic import
13:27:17  <devsnek>which is good enough imo
13:27:54  <caitp>that's not really dynamic though right, that's static
13:28:04  <devsnek>huh
13:28:13  <caitp>isn't it?
13:28:34  <devsnek>I don't understand the question
13:29:18  <caitp>like "sometimes this module's .then method is meant in the sense that it's a thenable, and sometimes it isn't --- thus it needs to be possible to change the "thenable" value dynamically"
13:29:57  <devsnek>well my opinion is that exporting a then function shouldn't change the behaviour between dynamic and static
13:30:39  <devsnek>they should always give you the same namespace (and dynamic import should always give you a namespace <.<)
13:31:12  <caitp>right, so what if you have a module like `import "async-thing" as ns; ns[Symbol.thenable] = false; export default ns;`
13:31:43  <caitp>is that the kind of thing that should be doable?
13:31:47  <caitp>and if so, why
13:31:57  <devsnek>setting the property would be no-op cuz namespaces are sealed
13:32:01  <devsnek>is my intuition
13:32:23  <devsnek>also it would be weird if other modules could change your modules behaviour
13:33:35  <caitp>yeah, that could be --- but then alternatively, `import "async-thing" as ns; export default Object.setPrototypeOf({ [Symbol.thenable]: false }, ns);` would be the same thing effectively right
13:33:45  <caitp>or close enough
13:33:51  <devsnek>no
13:34:12  <devsnek>hmm
13:34:58  <devsnek>again I don't think you can set the prototype of a namespace
13:35:13  <caitp>you're setting the prototype of the object you're exporting
13:35:29  <devsnek>that object is a namespace
13:35:38  <devsnek>and you did export default so it doesn't matter anyway
13:36:14  <caitp>the object is `{ [Symbol.thenable]: false, __proto__: <async-thing namespace> }`
13:36:41  <devsnek>right
13:36:49  <caitp>which, I believe, is legal
13:36:53  <devsnek>yea
13:37:11  <devsnek>so then you have some frankenstein default export
13:37:17  <devsnek>what's your point
13:38:25  <TabAtkins>I mean, there's no real difference between "you can toggle Symbol.thenable" and "you can toggle whether to use the 'then' name or something else".
13:38:46  <devsnek>yes there is
13:39:00  <caitp>I guess I'm asking if these are things that should be possible, e.g. dynamically changing the thenable-ness at runtime (of any object, not just a module), or if it should be a static value with the prototype ignored
13:39:01  <devsnek>definitely for dynamic import anyway
13:39:08  <devsnek>because the user doesn't add the symbol
13:39:28  <devsnek>in this case the production forces the static and dynamic to resolve the same thing
13:39:38  <devsnek>whether you use `then` or not
13:39:46  <caitp>(also, you can't export symbol-named properties in a namespace, right? don't they have to be identifiers?)
13:39:57  <devsnek>correct
13:40:17  <devsnek>well there might be private symbol exports but
13:40:23  <devsnek>that's another conversation
13:48:01  <caitp>so if you can't export symbol-named things, doesn't this mean it isn't really useful for making changing the thenable-ness of a module namespace with an exported callable "then"?
13:48:05  <devsnek>TabAtkins: do you see the difference in taking about? I want to make sure people understand what my motivation behind this is
13:48:20  <caitp>s/making//
13:49:07  <devsnek>caitp: the idea is that the symbol can't be changed on a namespace
13:49:19  <caitp>yeah but how do you put it on the namespace in the first place
13:49:37  <devsnek>in the production ModuleNamespaceCreate
13:49:47  <devsnek>Search that phrase in the spec
13:49:56  <devsnek>actually it's technically not even there
13:50:28  <devsnek>there's a place in the spec where Symbol.toStringTag is defined for a module namespace
13:50:29  <TabAtkins>devsnek: I mean, I see why having a thenable symbol is good (you can opt your object out of being a thenable when you're just wanting a .then() method for some other reason), but I don't see what makes the thenable symbol special here vs ".then or not" for determining whether something is thenable.
13:50:45  <devsnek>because then is just another name
13:50:57  <devsnek>there's nothing special about it for import
13:52:14  <caitp>but, how do you make an export named Symbol.thenable? I mean, you can't `export let Symbol.thenable = false;`, you can't `export { [Symbol.thenable], ... }`, etc
13:53:15  <devsnek>TabAtkins: and exports being stored in some object that is subject to thenable rules is almost an implementation detail
13:53:31  <devsnek>caitp: you don't make an export named symbol.iterable
13:53:53  <caitp>I don't understand how Symbol.thenable ends up on the namespace then
13:54:03  <caitp>in the proposal
13:54:05  <devsnek>the same way Symbol.toStringTag does
13:54:26  <caitp>ok I see
13:54:30  <caitp>so namespaces are never thenable
13:54:37  <devsnek>correct
13:54:51  <devsnek>that keeps the behaviour the same between dynamic and static imports
13:55:07  <devsnek>there shouldn't be something you can do to change those two things
13:55:19  <devsnek>whatever JavaScript mechanic it is, thenables or something else
13:55:23  <caitp>but then you could get this behaviour by just saying "if the resolution is not a module namespace object, ..."
13:55:32  <devsnek>yes you could
13:55:43  <devsnek>but they didn't want a random exception
13:55:54  <caitp>which brings me back to asking about the use-cases for this outside of modules
13:56:02  <TabAtkins>devsnek: Ok, right, so you're just saying that module objects should never be thenables themselves, which I agree with. ^_^
13:56:12  <devsnek>hype
13:57:17  <devsnek>the mechanic I chose was Symbol.thenable because it made people uncomfortable having specific exceptions in the resolve production
13:57:26  <devsnek>but I'm cool with whatever fixes this
13:57:51  <littledan>No idea why we'd have Symbol.thenable when Promises are always calling the "then" property
13:58:22  <devsnek>well in this case it isn't always
13:58:24  <littledan>the decision to make `await` be explicitly tied in with built-in Promises was a deliberate one. The natural way to change it would be to omit the thing where we wrap everything in a native Promise
13:58:51  <littledan>even when wrapping, you still end up calling the inner `then` function
13:59:01  <littledan>(sorry, jumping in in the middle)
13:59:06  <devsnek>it's ok
13:59:22  <littledan>anyway I don't think we need to start giving all properties Symbol names
13:59:33  <littledan>I think Symbol just makes sense when you need a different sort of namespace that doesn't collide
13:59:50  <devsnek>I would generally agree that we don't need oodles of symbols
13:59:59  <devsnek>I'm just not sure how else to go about this
14:00:18  <devsnek>you mentioned using a different kind of promise?
14:01:23  <devsnek>or did you mean like put the symbol on the Promise namespace
14:01:40  <caitp>I think the `await import(...)` behaviour wouldn't change, but the behaviour of resolving the dynamic import promise with a namespace with a "then" method would change
14:02:14  <caitp>because dynamic import returns its own promise anyway, right?
14:03:04  <devsnek>are people suggesting making dynamic import return a thenable instead of a promise
14:03:24  <devsnek>that wouldn't solve the problem would it
14:03:44  <caitp>*re-reads the dynamic import prop*
14:04:07  * jmdyckjoined
14:05:23  <devsnek>littledan: just to clarify, were you suggesting moving thenable to Promise or something else
14:07:36  <littledan>I don't know what you mean, but I am not suggesting anything
14:08:06  <devsnek>ok
14:08:40  <annevk>devsnek: are you also going to offer something for objects to opt-out of being array-like?
14:09:05  <devsnek>I mean
14:09:15  <devsnek>we already have Symbol.concatSpreadable
14:09:22  <devsnek>Symbol.arrayLike isn't far off
14:44:51  * jmdyck1joined
14:45:58  * jmdyckquit (Ping timeout: 264 seconds)
16:36:37  * jwaldenjoined
18:22:00  * cloudshujoined
18:23:00  <devsnek>so is finding a champion just like bugging delegates or is there some sort of process
18:25:49  * srl295joined
19:33:40  <bradleymeck>devsnek: mostly asking a member to take it to committee
20:14:43  <devsnek>icic
22:43:20  * bradleymeckquit (Quit: bradleymeck)
23:12:16  * bradleymeckjoined