It is a compile-time error to use "return;" without value.

[scheglov]

Tests:
language_2/void/return_future_or_void_sync_error4_test/none
language_2/void/return_future_future_or_void_async_error1_test/none
language_2/void/return_future_or_future_or_void_sync_error2_test/none
language_2/invalid_returns/async_invalid_return_03_test/none
language_2/invalid_returns/async_invalid_return_02_test/none
language_2/invalid_returns/sync_invalid_return_01_test/none
language_2/invalid_returns/sync_invalid_return_04_test/none
language_2/invalid_returns/async_invalid_return_01_test/none
language_2/invalid_returns/sync_invalid_return_02_test/none
language_2/invalid_returns/sync_invalid_return_05_test/none
language_2/invalid_returns/sync_invalid_return_03_test/none
language_2/invalid_returns/async_invalid_return_00_test/none
language_2/invalid_returns/sync_invalid_return_00_test/none
language_2/invalid_returns/async_invalid_return_04_test/none

co19_2/Language/Errors_and_Warnings/static_warning_t01
co19_2/Language/Statements/Return/no_expression_function_t01
co19_2/Language/Statements/Return/no_expression_function_t16
co19_2/Language/Statements/Return/no_expression_function_t10
co19_2/Language/Statements/Return/many_return_statements_t02
co19_2/Language/Statements/Return/no_expression_function_t07
co19_2/Language/Statements/Return/no_expression_function_t11
co19_2/Language/Statements/Return/no_expression_function_t04
co19_2/Language/Statements/Return/no_expression_not_function_t01
co19_2/Language/Statements/Return/no_expression_function_t08
co19_2/Language/Statements/Return/no_expression_function_t09
co19_2/Language/Statements/Return/no_expression_function_t05
co19_2/Language/Statements/Return/no_expression_function_t02
co19_2/Language/Statements/Return/no_expression_function_t03

[kmillikin]

It's valid if the return type is void, dynamic, or Null (or if the flattened return type is for asynchronous non-generator functions). For the other cases, we have been discussing with the language team that this will probably have to continue to be a warning, because making it an error is a breaking change.

I guess the issue for the language team is to make a decision and update the feature spec at https://github.com/dart-lang/sdk/blob/master/docs/language/informal/invalid_returns.md.

[eernstg]

@kmillikin, you mention updating invalid_returns.md, but it's not obvious to me what we'd make a decision about. Could you elaborate?

Maybe it's got to do with the errors/warnings listed in #34349?

[kmillikin]

Yes, exactly. It was decided that return; from a function with a return type other than void, dynamic, or Null would be a warning and not an error. The feature spec does not say that (it says "is an error" which seems wrong unless it's just being vague and you mean it's a warning.)

The feature spec needs a number of other updates:

It does not say what happens for an invalid return in the first part. Is it a compile-time error? Warning? Runtime error? Something else? It should be made clear.

It only characterizes the valid returns and does not ever say "and all other returns are invalid" which it should.

The second part says that the invalid returns are errors. Are they compile-time errors? Runtime errors? If it's meant to be an alternative and equivalent treatment then each part should stand alone. As I mentioned above, it should be explicit about which are errors and which are warnings.

[eernstg]

Indeed, thanks! I hadn't seen that return_without_value was among those, and we certainly need to update several documents (I thought that it would only involve dartLangSpec.tex). Added a note about this to #34349.

[kmillikin]

Also: it's simultaneously in status "implemented" and "ready for implementation" which (pedantically) isn't wrong but it's more confusing than simply "implemented".

And can we please rename this feature spec to invalid-returns.md? It's the only one that has an underscore in its name and I keep forgetting that when I go to search for it. Since we've linked to it, we could leave a document at invalid_returns.md that says it's moved.

[eernstg]

This CL adjusts dartLangSpec.tex such that the compile-time error mentioned above is changed to a warning.

[eernstg]

Said CL was landed as e4e82da.

@kmillikin wrote:

status .. confusing .... rename .. to invalid-returns.md

The status is now 'background material .. please consult the language specification'. This would be less ambiguous, and it makes the need to rename less urgent, so I'll consider those issues to be resolved at this point.

invalid returns are errors. Are they compile-time errors? Runtime errors?

The language specification text is explicit on this topic, for example here, so I think this has been resolved as well:

It is a compile-time error if $s$ is \code{\RETURN{};},
unless $T$ is \VOID, \DYNAMIC, or \code{Null}.

I believe that there are no remaining 'area-language' issues here, so I'll remove that label.