Design MethodScript casting behavior

Empieza leyendo el Proposed casting design y los pull requests relacionados #1401, #1402 y #1420; no se identifican archivos fuente ni pruebas. Se considerará terminado cuando se resuelva el trabajo restante de casting y comprobación de tipos descrito en la propuesta, incluido el comportamiento especificado de los casts suaves, estrictos e implícitos.

Introduction

When static analysis is enabled in the MethodScript configuration, MethodScript code will be typechecked. For scripts that are fully statically typed (i.e. all variables, procedures and closures are declared with a type / parameter types and return type), it should be impossible for a type to accidentally be used as a different type (which is called type safety of a program). When a type error occurs, it will be a compile-time error that can't be missed by the programmer. This is a powerful feature that can prevent many user mistakes.

TODOs / Problems in the current typechecking implementation

The following features are currently missing in the typechecking implementation (this list might not be complete):

• Procedure arguments are not typechecked against their parameter declaration types.
• Closure arguments are not typechecked against their parameter declaration types. This often won't be possible since the closure signature is not part of the closure data type.
• Procedure and closure return types are not typechecked (the type of @value in return @value against the declared return type).
• Many functions do not yet have a getSignatures() implementation (that is used for obtaining type info for typechecking).
• There exists no way to cast values to any other specific type.

The last point in this list is the most severe problem with typechecking. Without a cast operator, it becomes impossible to fully statically type many programs. Lets say a function return mixed and you know from the documentation of that function that it will return an int for your usage, then a cast is necessary to convert the mixed value into an int value before it can be used as an int. If the cast is omitted, it will result a compile-time type error.

This issue exists to document the result of discussions around the implementation of multiple types of casts in MethodScript.

Proposed casting design

Cast types

Three casting types are proposed:

[IMPLEMENTED] Explicit non-converting "soft" casts.

Syntax: (type) val (i.e. (int) @val).
This cast is mainly a compile-time check that tells static analysis what the type of a value is. In runtime, it will check whether the given value really is an (indirect) instance of the type that it was cast to and throw a CRECastException if it is not. This type of cast is merely a check and will never adjust the passed value in any way.

Explicit converting "hard" casts.

Syntax: val as type (i.e. @val as int).
This cast acts like a "soft" cast with the additional behavior that it converts the passed value into the casted-to type only if such conversion is both necessary and possible (i.e. 123 as string will result in string '123', '45' as int result in int 45 and 123.45 as int will result in int 123). Such a conversion can be lossy and irreversable. When the passed value is not instance of the passed type and conversion is not possible, a CRECastException is throws.

Implicit converting casts.

Syntax: None.
This cast will occur when a type is used as a more wide type (i.e. a uint8 value used as a uint16 in C). in MethodScript the use-cases for this cast are very limited, but not irrelevant. This cast will allow using any int value as a double. A consideration can be to only allow usage of int literals where a double type is expected, and not allow this in the general case.

Proposed casting implementation

The three types of casts as well as the other listed open problems can be implemented completely separately. Proposed priority is:

• [IMPLEMENTED] Explicit non-converting "soft" casts.
  Adds possibility to statically type scripts without getting stuck on the lack of a cast operator.
• Function signatures of many functions (basic MethodScript functions such as the Math and DataHandling functions have priority).
  Allows the type checker to check more commonly used code and cause more needs for casting in the process.
• [IMPLEMENTED] Procedure parameter typechecking.
  Allows the type checker to check more code and cause more needs for casting in the process.
• Implicit converting casts.
  This is likely easy to hack into the type checker if this will really just allow usage of int values as double.
• Explicit converting "hard" casts.
  This cast is the hardest to implement due to the need for a good code structure that allows conversion between many different types in such a way that future MethodScript user objects can conveniently make use of the same code structure. Essentially this should follow the behavior of currently implemented conversion methods in the ArgumentValidation class.

Relevant pull requests

• #1401
• #1402
• #1420