Return after halt() being ignored can be confusing about chapel HOT 6 OPEN

In my view, the expectation that code after a halt() will do anything is legacy. For today's Chapel, I see it "normal" to declare the return type explicitly rather than relying on return-after-halt.

Given the importance of abstract classes and pure virtual methods it makes sense to introduce language support for them. A library routine, an attribute, or some syntax (cf. init tnis) are possibilities.

That said, if others find return-after-halt valuable, I can live with it.

from chapel.

Of course we can consider other ways to indicate something is pure virtual, such as an attribute or keyword. See also #8566 and #15271.

Given the importance of abstract classes and pure virtual methods it makes sense to introduce language support for them.

Good points and I would also prefer language support for pure virtual methods than continuing to use this pattern to fake it.

from chapel.

Tagging @vasslitvinov and @DanilaFe on this due to their involvement with #23309. Note that I consider this low priority (but worth capturing).

from chapel.

#20673 raises other related questions.

We should at the very least add a clarification to the spec here.

from chapel.

IMO for the specific pattern here, we could introduce a library routine to call to indicate a method is "pure virtual" / "abstract" and call that instead of halt. Then, the compiler can be adjusted to not consider this to make the return dead code. Of course we can consider other ways to indicate something is pure virtual, such as an attribute or keyword. See also #8566 and #15271.

I would also be open to an approach that uses such top-level returns for type inference of routine return types even if there is halt before it, possible as an exception to the general dead code / param folding rules.

from chapel.

I agree with Vass and think it would be reasonable for the language to detect and warn against this pattern, perhaps suggesting you annotate a return type instead. I also think it would be reasonable to try and warn for all unreachable code that is not being deliberately param folded away.

from chapel.