fe, tests: Type inference for formal arguments #1722
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
NOTE: This is experimental, would like to gain experience and know if this is useful or does harm.
With this patch, formal arguments types in a feature declaration can be omitted provided that the currently compiled module has a call to the formal argument's outer feature that provides an actual argument that permits type inference.
As an example, here is the first example from https://flang.dev/tutorial/feature_decl_fields
Type inference permits omitting all formal argument types in this example, so we can omit
i32
andPoint
types forx
,y
andp
and writeThis looks like magic, but it is in fact just a removal of redundant information, the language is still fully statically typed. One caveat is that the documentation function of types in the source code gets lost, in particular since the call to a feature may be far away from its declaration, even in a separate file, but always in the same module. Documentation tools like
fz -docs
operate after the front end is done, so they should have full type information.This, however, also creates new possibilities for errors: First, there might be several calls to the same feature with incompatible actual argument types. Second, there might be no call at all so the argument type is unknown. Both cases result in new errors.
A new negative test
typeinference_for_formal_args_negative
checks these error cases.