-
Notifications
You must be signed in to change notification settings - Fork 790
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC FS-1093] Additional type directed conversions #10884
Conversation
Test failures (all expected, at a first glance)
|
This would implement fsharp/fslang-suggestions#849 |
I set up auto-flow from |
* [main] Update dependencies from dotnet/arcade (#10913) Microsoft.DotNet.Arcade.Sdk From Version 6.0.0-beta.21068.2 -> To Version 6.0.0-beta.21069.2 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> * Refactor everything but the type provider tests in signature help testing (#10908) Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Phillip Carter <[email protected]>
Testing this branch along with anonymous union. type DU = DU of int
let _: obj = DU(0) //error FS0001: This expression was expected to have type ...
type R = { a: int }
let _: obj = { a = 0 } //error FS0001: This expression was expected to have type ...
let _: obj = {|a=1|} // works
[<Measure>]
type id
type UserId = int<id>
let id: UserId = 0<id>
let _: obj = id // works Edit: just noticed your notes on record which is todo😛 |
But we can still disable automatic upcasting at override returns (and go on the error path before this PR) and emit a covariant return instead? |
Like type [<AbstractClass>] A() =
abstract A: unit -> obj
type B() =
inherits A()
override A() = () // Covariant return
type C() =
inherits A()
override A() = Unchecked.defaultof<_> // Infer obj since type inference kicks in and no other type is known
type D() =
inherits A()
override A() = () :> _ // Infer obj type for type hole |
I don't think so, because existing code already relies on the eager application of the non-covariant type information. To be honest, co-variant returns are just unlikely to ever make it into F#. Remember F# strongly biases against class/interface hierarchies as a modelling technique (though this stuff does have its uses). If we ever add them, I'm pretty certain we would want strong type information for updated types for the slots.
|
@KevinRansom This is now ready for preview. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a few things
tests/FSharp.Compiler.Service.Tests/FSharp.Compiler.Service.Tests.fsproj
Outdated
Show resolved
Hide resolved
I'll fix the test issues |
…s_for_auto_widen
merge main and Fix tests for auto widen
@KevinRansom thanks! |
@KevinRansom all ready I think |
Implementation of RFC https://github.com/fsharp/fslang-design/blob/master/FSharp-6.0/FS-1093-additional-conversions.md
This primarily loosens the auto-widening rules in the presence of explicit type annotations or other "known" type information, e.g. to allow things like:
It also adds
int32 --> int64
conversions and a limited form ofop_Implicit
support.In this PR the rule is:
When processing an expression the "overall type" is usually labelled as "MustConvertTo" the known type, instead of "MustEqual"
This is propagated over if/then/else and other control structures. So if
if then A then B
must convert to T, then both A and B must convert to T, but A and B may have different types.For leaf expressions, we often have immediate knowledge of both the source and MustConvertTo types. If a unification between the two would have failed then subsumption and adhoc conversions can be tried instead.
The adhoc conversions enabled are in the RFC.
This also allows (the removal of upcast coercions like
asExpr
on this line](https://github.com/dotnet/fsharp/blob/main/src/fsharp/FSharp.Core/Linq.fs#L282), e.g. in favour of one explicit type annotation.A longer list of things enabled is below and in the RFC