| 06:27 | <Domenic> | If "the iterative approach" means "do one of those steps at a time", then that's good. If "the iterative approach" means "spec something new nobody is doing, possibly with a new API nobody ships currently", then that's bad. |
| 08:03 | <ljharb> | the structure i've had in the proposal since 2019 is exactly what everyone's already doing. it does add some new APIs nobody ships as well (whose implementation basically matches what everyone's already doing), but i'm not sure why that would be bad, that's just what almost every proposal is (adding a new thing). |
| 08:09 | <littledan> | Yeah I agree that it would be good to start this project with finding what JS implementations put in their stack traces and comparing them. Just doing that without the subsequent steps would be an interesting and meaningful report, helping any future stack trace API effort |
| 16:14 | <snek> | i think all of the error stringification should be removed from this proposal |
| 16:15 | <snek> | or at most, say that Error.prototype.stack and "string" are both the result of some implementer defined AO |
| 20:51 | <ljharb> | that wouldn't constrain the format/structure tho, so what would be the value |