Match blocks returning matched expression when no branch matches about clue HOT 23 CLOSED

I think that's something that may cause a behavior unexpected by some developers, maybe enforcing a complete match like Rust would do but that needs the type system

from clue.

Maybe in the future, but since this is quite an issue we should fix it in 3.3 (maybe...)
An easy solution is to set _internal0 to nil using an else at the end, but should we?

from clue.

That may be the right solution for now, but probably will break compatibility with 4.0 (if a better match will be implemented, but that's not so much a problem)

from clue.

The main worry I have is that it technically could break compatibility with 3.2 as well, since some code may actually rely on this bug

from clue.

It was never documented to do such a thing so I'd say that's better changing than not

from clue.

Hm, true, we should fix it then yeah

from clue.

Since not this is intended behavior and is considered a bug we can fix it. I would say just set it to nil if nothing matches with an else block

from clue.

I think you meant to say "Since this is not intended behaviour"?

from clue.

Absolutely agree that if no cases match, the expression should evaluate to nil. Of all things that could happen, having it evaluate to the scrutinee probably has the highest "WTF" factor!

from clue.

Yeah it confused me a lot when I discovered it

from clue.

As for implementation, I imagine it shouldn't be too difficult as it is equivalent to there being an implicit:

_ => nil,

…at the end of every match block.

from clue.

I think it should be easy enough to do, but I'm not sure.

from clue.

I think it should be easy enough to do, but I'm not sure.

probably clue should maybe print a warning about this

from clue.

a...warning?

from clue.

at least if I made a linter it would be a warning, but to the context of only the compiler I guess it wouldn't be required

from clue.

It should be best to just fix it altogether by setting it to nil, I think

from clue.

It should be best to just fix it altogether by setting it to nil, I think

It should be fixed but using this is sort of bad code

from clue.

Clue never complains about bad code anywhere else, so...

from clue.

Clue never complains about bad code anywhere else, so...

on this should we make a linter for 4.0?

from clue.

I think 4.0 is already a daunting task as is, maybe later on..

from clue.

You could have a warning for cases where the user is clearly doing something that doesn't make sense (like the example in the original post), but it's more commonly going to happen accidentally. What's the use case for matching on a constant? If you're matching on a variable, then without a type system, you're not going to know if the match could fail.

from clue.

having the fail be shown by returning the matched variable also doesn't help

from clue.

This issue has now been fixed.

from clue.