Geoff Romer

> > However, in Carbon we want [APIs to be provided by the library](https://github.com/carbon-language/carbon-lang/issues/1725) > > That link is to this issue; did you mean to link elsewhere? I'm guessing...

> The official Carbon spellings of C++'s `p->x` and `v.x` are `p.->x` and `v..x` (or whatever bikeshed color you like). These are ugly, but will almost never be seen. Insted,...

> True, although that's not entirely a new problem: adding methods to a base type can already break subtypes. Yes, but you can avoid that problem by disallowing inheritance from...

FYI I haven't forgotten this, but I'm having trouble finding someone who's able to review it.

What problem(s) are you trying to solve?

> Never mind, the proposal seems to suggest that `Match` is itself a generic function. Does this mean there is in theory a version of `Match` for every place where...

The Explorer is currently using Flex and Bison (see [`lexer.lpp`](https://github.com/carbon-language/carbon-lang/blob/trunk/explorer/syntax/lexer.lpp) and [`parser.ypp`](https://github.com/carbon-language/carbon-lang/blob/trunk/explorer/syntax/parser.ypp)), I think mostly because they're widely available. I don't think anybody's looked much into the costs and benefits...

I would recommend aiming for a more general feature, for a few reasons: - All else being equal, it's better not to impose limitations unnecessarily. - We generally try to...

> I'm assigning this to @geoffromer to decide which he thinks should really work best -- this area isn't fully designed yet and he was thinking it over. I'm afraid...

I understand this issue report to be about two closely related problems: - The Explorer does not support the declaration syntax for alternatives that's in the current language design. -...