> Carbon: graduating from the experiment
https://ndctoronto.com/agenda/carbon-graduating-from-the-exp...
As for it being widely adopted, people keeping missing the point that Carbon is mostly for Google themselves, as means to integrate into existing C++ projects.
They are the very first ones to assert that for green field projects there are already plenty of safe languages to chose from.
In case that you are well familiar with for instance pattern matching, might you have any opinions on the pattern matching that is currently proposed for Carbon?
https://docs.carbon-lang.dev/docs/design/pattern_matching.ht...
Regarding the linked pattern matching proposal, it seems alright to me, not everything has to be ML like.
match (0, 1, 2) {
case (F(), 0, G()) => ...
}
> Here (F(), 0, G()) is not an expression, but three separate expressions in a tuple pattern. As a result, this code will call F() but not G(), because the mismatch between the middle tuple elements will cause pattern matching to fail before reaching G(). Other than this short-circuiting behavior, a tuple pattern of expression patterns behaves the same as if it were a single expression pattern.How would that work with exhaustiveness checking? As far as I can tell, they themselves believe that Carbon's exhaustiveness checking will be very poor.
And OK with implicit conversions? Especially when combined with their way of handling templates for pattern matching?