[RFC FS-1069] Implicit yields (allow dropping yield in list, array, sequence and computation expressions)

[dsyme]

This is the implemntation for RFC FS-1069 Implict yields, i.e. the "implicit yields" language suggestion. This allows implicit yield in list, array, sequence and those computation expressions supporting Yield/Combine/Zero/Delay.

See the RFC for notes and discussion

[dsyme]

The simplest, most compatible rule seems to be "implicit yields are enabled if there is no explicit 'yield' in the computation expression"

I have also added the implementation of this rule for computation expressions (rather than just array/list/sequence expressions) using yield

[auduchinok]

We need to consider if this applied to other computation expressions, or just sequence/list/array expressions.

I'd be glad if it worked in other cases too.

[dsyme]

I'd be glad if it worked in other cases too.

I've

1. added the general implementation for computation expressions
2. expanded the testing
3. clarified the proposed rules in this issue (getting it closer to a draft of an RFC)

[vasily-kirichenko]

Why not enable this for yield! as well? If an expression has type that implements seq<'a> where 'a is the (inferred) type of elements of the computation expression, why not just implicitly yield! it?

[dsyme]

Why not enable this for yield! as well? If an expression has type that implements seq<'a> where 'a is the (inferred) type of elements of the computation expression, why not just implicitly yield! it?

It's a good question. My intuition is it's just too much, too implicit, both for type inference and for users. I don't have proof of this though.

[forki]

Don't think it's a good idea to implicitly mix map and flatmap. Usually I want to know when flattening is happening. In react view code it's usually a sign that I want to refactor or that I need to add fable.react's ofList function that gives better perf Don Syme <notifications@github.com> schrieb am Di., 19. März 2019, 12:31:

…

Why not enable this for yield! as well? If an expression has type that implements seq<'a> where 'a is the (inferred) type of elements of the computation expression, why not just implicitly yield! it? It's a good question. My intuition is it's just too much, too implicit, both for type inference and for users. I don't have proof of this though. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6304 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNLkLZN-yMAYmx4-7tyzLwQaQPFrEks5vYMqDgaJpZM4baZth> .

[dsyme]

Unrelated flaky test failure:

[xUnit.net 00:01:16.59]     FSharp.Core.UnitTests.FSharp_Core.Microsoft_FSharp_Control.AsyncType.TaskAsyncValueException [FAIL]
Failed   FSharp.Core.UnitTests.FSharp_Core.Microsoft_FSharp_Control.AsyncType.TaskAsyncValueException
Error Message:
 System.TimeoutException : The operation has timed out.
Stack Trace:
   at Microsoft.FSharp.Control.AsyncPrimitives.RunSynchronouslyInAnotherThread[a](CancellationToken token, FSharpAsync`1 computation, FSharpOption`1 timeout)
   at Microsoft.FSharp.Control.FSharpAsync.RunSynchronously[T](FSharpAsync`1 computation, FSharpOption`1 timeout, FSharpOption`1 cancellationToken)
   at FSharp.Core.UnitTests.FSharp_Core.Microsoft_FSharp_Control.AsyncType.TaskAsyncValueException() in D:\a\1\s\tests\FSharp.Core.UnitTests\FSharp.Core\Microsoft.FSharp.Control\AsyncType.fs:line 424

[isaacabraham]

@vasily-kirichenko how would you distinguish what the return type of this is - is it int list or int list list?

let x =
  [
      [ 1 .. 5 ]
  ]

What about these cases

let y =
  [
      [ 1 .. 5 ] // implicitly yield! ? Or is it int list list?
      1 // compiler error?
  ]

let z =
  [
      1
      [ 1 .. 5 ] // compiler error? implicitly "yield!" ?
  ]

On the one hand, I get the idea of making this "simpler" to look at, but on the other hand I find this "implict" yield (and especially yield!) feels to me to be going against the explicit and (very importantly) predictable nature of F#. I feel that this feature would have to be very clearly documented to explain what and why is happening.

[dsyme]

Closed in favour of #6806