You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The language compiler currently attempts to use any available explicit type conversion when there is a type mismatch in available method overloads. In most cases the conversion is only attempted if there is indeed an explicitly declared type conversion available in the type. However, in some cases a coercion is attempted without the check, and there is one specific situation that significantly compromises the type safety of the build system.
It happens when multicasting an observable sequence into a subject, where both the type of the sequence and the type of the subject are interface types. In most cases attempting the conversion directly in the expression tree matches the behavior of overload resolution. For example, when converting a concrete class to an interface, the compiler knows the list of interfaces implemented by the type, so if an interface is not allowed, a casting error will be reported.
However, if we hold a type which is already an interface type, there is no way of knowing how many other interfaces the specific instance behind the interface might implement (since C# allows for multiple arbitrary interface implementations). This means there is really no compile-time constraint on the explicit cast and the conversion is allowed, with its evaluation deferred to be performed at runtime.
In the case of multicasting to a subject, this behavior is overly permissive and should not be allowed since it is essentially the same as treating every single interface type as an object which can be multicast into any subject, thus compromising the value of type inference. Instead, overload resolution rules should be used to check whether there is an available conversion from the sequence type to the subject type.
For example, the following should not build:
The text was updated successfully, but these errors were encountered:
glopesdev
changed the title
Do not allow automatic type conversion between interfaces
Do not attempt a blind type conversion when multicasting to subject
Jul 6, 2023
The language compiler currently attempts to use any available explicit type conversion when there is a type mismatch in available method overloads. In most cases the conversion is only attempted if there is indeed an explicitly declared type conversion available in the type. However, in some cases a coercion is attempted without the check, and there is one specific situation that significantly compromises the type safety of the build system.
It happens when multicasting an observable sequence into a subject, where both the type of the sequence and the type of the subject are interface types. In most cases attempting the conversion directly in the expression tree matches the behavior of overload resolution. For example, when converting a concrete class to an interface, the compiler knows the list of interfaces implemented by the type, so if an interface is not allowed, a casting error will be reported.
However, if we hold a type which is already an interface type, there is no way of knowing how many other interfaces the specific instance behind the interface might implement (since C# allows for multiple arbitrary interface implementations). This means there is really no compile-time constraint on the explicit cast and the conversion is allowed, with its evaluation deferred to be performed at runtime.
In the case of multicasting to a subject, this behavior is overly permissive and should not be allowed since it is essentially the same as treating every single interface type as an object which can be multicast into any subject, thus compromising the value of type inference. Instead, overload resolution rules should be used to check whether there is an available conversion from the sequence type to the subject type.
For example, the following should not build:
The text was updated successfully, but these errors were encountered: