On type annotations

[mkitti]

@Matthijs_1971

Because after the annotation, the type of vec can not change any more. That improves maintainability and readability of the code.

My current sense is that while the above is the intention, the proposed solution of a left hand type assertion, binding the variable to the type, also has the effect of inviting conversion when it is not desired.

In a prior discussion, a @returnassert macro was developed to just assert the return type of a function, without any implicit conversion.

Semantics of :: in return type vs. argument type annotations

An issue with return statements is that they are not always needed, and I don’t see how a macro could easily determine all possible return values of a function when not all of them are associated with an explicit return. For a macro-based approach, I’d rather use an approach in which a function definition like this: @returnassert function foo(x, y) :: Float64 if (rand() > 0.5) return x + y end # no explicit return here x - y end is transformed into something like this…

@Matthijs_1971

    other::OtherStruct = calculate_other_struct(value, obj, vec)

The above line invites implicit conversion. A macro that rewrites all left-hand assertions to be as follows or lowers the left-hand assertions and then removes the conversions might be a more appropriate tool for static typing.

    other = calculate_other_struct(value, obj, vec)
    other::OtherStruct

Here we ensure both that

1. other does not change type
2. The right hand side also does not change type.

What I imagine with the large number of structs is there actually may be a need to convert between the structs and thus unintentional conversion could be a real issue for these structs, not just numeric types.

In summary, my thought here is that we need another tool here other than the left-hand variable assertion or the function return type assertion. In the near term, this may mean a specialized macro, like the referenced @returnassert to accomplish this goal without the implicit conversion side effects. In the long term, we may need a different kind of type assertion or assignment syntax.

Somewhat missing from the discussion are the use of type parameters to both enforce expectations and provide flexibility.