undefined

points

[-]

What concerns me is that the design of Carbon in aspects seem to have serious issues already now.

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...

by pjmlp5 hours ago|

parent|

[-]

I am not a Google employee, as such I don't care where they take Carbon, other than being a technology nerd that had compiler design as one of the areas I majored in.

Regarding the linked pattern matching proposal, it seems alright to me, not everything has to be ML like.

by ceteia4 hours ago|

parent|

[-]

Are you really OK with runtime "expression patterns"?

    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?

by pjmlp3 hours ago|

parent|

[-]

As mentioned I have no interest in ever using Carbon, the language still isn't 1.0, and full end to end compiler is yet to be made available.