[chuck-users] Bad return signature in pre-constructor leads to null instance

[Kassen]

Robert;


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

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20090312/b7ac0250/attachment.html>