Did you spot the difference? "bad_pre_constructor" is declared (improperly) to return a float, but it doesn't, and an instantiation of Foo silently returns a null. "good_pre_constructor" is properly declared with a void return, and an instantiation of Foo returns a good value.
Ah, yes. I think this has been under debate before; functions that claim they will return something must return this and ChucK doesn't verify that it does. I think it was debated in some depth on the forum. Part of the problem is that it's not clear ChucK could know a function will always return when we do know this. Consider this;
fun int invert (int input)
{
if (input == 0) return true;
else if (input == 1) return false;
}
We may know that this function will only get fed a 1 or a 0 and so it may be "safe" but if it would get a 3 then there will be a issue. While this may be ok in certain contexts I'd always re-write it like this;
fun int invert (int input)
{
if (input == 0) return true;
else return false;
}
What we could do is require a function of a non-void type to have a "return" statement somewhere in it, maybe even require that it should be on the last line and outside of any conditions and issue a complaint otherwise, but that will outlaw some types of functions that may be perfectly fine. I'm a bit scared that rules that will prevent improper functions from being written at all will also stifle creativity; in many cases us programmers are a lot more clever than parsers are. That said; I think it's good form to always end functions of a non-void type with a return statement, even if it's just "else return false", often I will make it print a warning if it fails in such a way due to unexpected input.
Some people insist on only having a single return statement on the last line. While that's very safe I feel it can lead to overly complicated constructs that I don't find as pleasant to read or write and that proper indentation and syntax highlighting can make it clear other strategies are safe as well; the second example I gave above does that and I consider that one quite natural and readable as well as clearly safe.
The only reason I can think of -right now- to not have a return statement on the last line and outside of any conditions is when we would want to kill the whole shred on that line. While strictly speaking this is valid and might be useful that's far from clean and will likely lead to readability issues but is that really a reason to ban such tricks? I mean; maybe our foot is rebelling against us, we may have a valid reason for shooting it ;¬).
This is not friendly behavior.
I agree, but it's not clear what proper behaviour should be either. For now I'm inclined to have compilation halt if the "return" keyword isn't used in a function that is of a non-void type and leave the programmer to make sure it will return in each and every case. That would at least catch simple typos in the definition of the function type and give a fair warning.
P.S.: Uh, is this the right forum for reporting bugs like this?
Absolutely. It's interesting that you found that this issue (which in itself was known) will prevent object instantiation as well. I agree with you that the current behaviour can lead to lengthy searches due to only making a single typo.