Missing return statement does not trigger warning or error.

[DartBot]

This issue was originally filed by [email protected]

---

What steps will reproduce the problem?

Type the following in try-dart-lang.appspot.com:

num foo() {
  print('Hello, world!');
}

main() {
  foo();
}

Or, even more egregiously:

num foo() {
  print('Hello, world!');
}

main() {
  num result = foo();
}

What is the expected output? What do you see instead?

Since the declaration of foo() promises to return an object of type 'num', there should, at the very least, be a warning triggered as a result of the lack of return. Ideally this would be an error.

Please provide any additional information below.

[DartBot]

This comment was originally written by [email protected]

---

Every method returns a value, and if there is no return it is null and null is a valid "num" value. However, I agree this is likely to be an error, so a warning seems in order.

Does this also behave the same in the VM?

---

Added Area-Compiler, Triaged labels.

[DartBot]

This comment was originally written by [email protected]

---

I don't have the VM installed yet, so haven't tried it.

[DartBot]

This comment was originally written by [email protected]

---

FWIW, Dartc actually matches the VM behavior. I don't believe that this is currently specified in the language spec.

[DartBot]

This comment was originally written by [email protected]

---

Set owner to [email protected].
Added Accepted label.

[DartBot]

This comment was originally written by [email protected]

---

According to the spec (Draft Version 0.03)

"If the last statement of a function is not a return statement, the statement return null; is implicitly appended to the function body."

Since null is of type 'bottom' it seems it should not 'strictly' be a type error.

Even though the spec is silent about type warnings in this case, It seems appropriate as a friendly reminder to the user of a possible unintended consequence.

[DartBot]

This comment was originally written by [email protected]

---

FYI, section 11.10 of the same document has the following clause which I believe supersedes the one referenced:

"Hence, a static warning will not be issued if f has no declared return type, since the return type would be Dynamic and Dynamic may be assigned to void. How- ever, any function that declares a return type must return an expression explicitly.
This helps catch situations where users forget to return a value in a return statement."

[DartBot]

This comment was originally written by [email protected]

---

We plan to revisit return statement validation rules at the language level.

[DartBot]

This comment was originally written by [email protected]

---

I agree with mmendez, the spec states that, though it seems contradictory (another reason why it seems appropriate to handle this issue as a language matter for now).

On one hand it says an "implicit return null.." would be added therefore the bottom type would not cause type warnings, on the other hand it says "any function that declares a return type must return an expression..." as you pointed out. I will leave the issue assigned to Gilad for clarification.

[DartBot]

This comment was originally written by [email protected]

---

Set owner to @gbracha.

[DartBot]

This comment was originally written by [email protected]

---

Removed Type-Defect, Area-Compiler labels.
Added Type-Enhancement, Area-Language labels.

[anders-sandholm]

Added apr30-triage label.

[anders-sandholm]

Removed apr30-triage label.

[anders-sandholm]

Added triage1 label.

[anders-sandholm]

Added this to the M1 milestone.
Removed triage1 label.

[alan-knight]

I got bitten by this the other day, where I omitted a return statement and carefully computed a value that was then discarded, and it was tricky to realize that. So, we've accepted this bug, but what is it that we've accepted to do? I think my preference would be that if a method is not declared void and does not return a value, that it would be a warning. Or possibly if it's explicitly declared some return type? I'm thinking of the case where I'm writing untyped code and the methods aren't saying whether or what they expect to see returned, and I don't want them to give me a lot of warnings about it.

[gbracha]

Karl actually did a prototype with a bunch of type rules that mostly capture what you want, but some things are tricky. Long discussion.

[alan-knight]

OK. And actually, I wonder if at the editor level it might be useful to warn that you were using the return value of a function/method that did an implicit return. There are probably some hairy edge cases there, but it avoids the issue of the dynamic case.

[sethladd]

Issue #4204 has been merged into this issue.

[gbracha]

Removed this from the M1 milestone.
Added this to the M3 milestone.

[sethladd]

Analyzer reports when a function doesn't return, but is marked with a type.

Should we close this?