| 00:01 | <bradleymeck> | devsnek: not currently, forgot to ask for stage 1 so never made one |
| 00:01 | <devsnek> | oh |
| 01:42 | <bendtherules> | jmdyck: i meant how symbol is converted to string using "[" + description + "]". |
| 01:42 | <bendtherules> | That doesn't seem like a convention which is used in other places. |
| 01:42 | <bendtherules> | And also someone noticed that if description is empty, it becomes just [], which might be confused with arrays. So, instead it's kept as just empty string. |
| 01:43 | <jmdyck> | symbol isn't converted to string via "[" + description + "]" |
| 01:43 | <jmdyck> | the symbol-to-string part happens at "Let description be name's [[Description]] value." |
| 02:55 | <bendtherules> | jmdyck: i think we are talking about different sections of the spec. I am talking about - https://tc39.es/ecma262/#sec-setfunctionname |
| 02:55 | <jmdyck> | that's what i was talking about too, see step 4.a |
| 02:57 | <bendtherules> | Ok, got your point. Yes, technically 4 a gives the description which is a string. |
| 02:57 | <bendtherules> | But that is not the final name which is set to the function |
| 03:00 | <jmdyck> | perhaps you could restate your question/concern/point? |
| 03:05 | <bendtherules> | My question was, is this a convention when a symbol is represented by a string? (description being surrounded by "[]") |
| 03:05 | <bendtherules> | Is there any other place where a symbol is represented using this format? |
| 03:08 | <jmdyck> | Well, that's easy enough to check for yourself: just look for how [[Description]] is used in the spec. |
| 03:11 | <bendtherules> | Yes. So i saw that symbol.toString does - "Symbol(", desc, and ")". |
| 03:12 | <bendtherules> | Is there any reason why these two representations are different? |
| 03:13 | <jmdyck> | Dunno. Probably. |
| 03:18 | <bendtherules> | Got it. I understand that there was probably some discussion around it. |
| 03:18 | <bendtherules> | So if someone remembers such a discussion or can point to something - that will be helpful. |
| 03:18 | <bendtherules> | (i looked in the notes and couldn't find with basic search) |
| 03:21 | <jmdyck> | Looks like it was introduced in one of the early drafts of ES6, is November/December 2012 |
| 03:21 | <jmdyck> | s/is/in/ |
| 03:22 | <jmdyck> | Symbol, that is. |
| 03:24 | <bendtherules> | Hmm, i found notes for symbol.description - but that's probably the public property |
| 03:25 | <bendtherules> | And is there any old documentation for these es6 era discussions? |
| 03:26 | <jmdyck> | theoretically, yes |
| 03:28 | <jmdyck> | meeting notes would be posted to the es-discuss list |
| 03:43 | <bendtherules> | Ok, i will try to look there |
| 04:02 | <devsnek> | bendtherules: it's a parallel of computed properties |
| 04:03 | <devsnek> | i.e. representing an expression in an identifier context |
| 04:06 | <bendtherules> | Ok. So this convention was chosen because it looks like a computed property? |
| 04:06 | <bendtherules> | I mean using square brackets around the description makes it look like a computed property |
| 04:07 | <devsnek> | yeah, all well known symbols have a description of the way you access them |
| 04:07 | <devsnek> | for example `Function.prototype[Symbol.hasInstance].toString()` will give you something like `'function [Symbol.hasInstance]() { [native code] }'` |
| 04:32 | <bendtherules> | Isn't that a side-effect of this rule, though? |
| 04:35 | <bendtherules> | Ok, i guess not. Because this is not a normal function, and wasn't created using `Function.prototype[Symbol.hasInstance] = function(){} `. |
| 04:35 | <bendtherules> | It is just made to have a similar name |
| 05:24 | <ljharb> | bendtherules: what else would you expect `({ [Symbol.iterator]() {} })[Symbol.iterator].name` to be? |
| 05:47 | <bendtherules> | ljharb: Well it could have been "Symbol(Symbol.iterator)" just like how `Symbol.iterator.toString()` works |
| 05:49 | <bendtherules> | (i am not saying that that should be the case, but it's little odd that symbols can get "stringified" in 2 different ways - depending on .toString or NamedEvaluation |
| 05:49 | <bendtherules> | ) |
| 05:49 | <ljharb> | fair |
| 05:50 | <ljharb> | bendtherules: i think the difference is that the toString is meant to tell you about the symbol, the name is meant to tell you about the function itself |
| 05:53 | <bendtherules> | Hmm, makes sense. I am sure there would have been some discussion around this - so just wanted to find that. |
| 05:54 | <ljharb> | github.com/tc39/notes would likely have it |
| 05:55 | <bendtherules> | I searched there, but couldn't find it. There is some discussion around Symbol.description - but I think that is just about internal desc getting exposed through public property |
| 05:56 | <bendtherules> | There is also the es-discuss list, but it's little hard to search. Will try to search more later. |
| 14:37 | <devsnek> | bendtherules: you can run a git blame on the spec to see which commit introduced it |
| 16:43 | <ljharb> | devsnek: that predates git for the spec |
| 16:43 | <ljharb> | we moved to git somewhere between ES2015 and ES2016 |
| 19:46 | <jmdyck> | specifically, for the start of ES2016 development |