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
I propose we allow writing an infix expression with not the same oprand type
(I do not know how to exactly explain it but it is something like this:
let inline(<<) a x =(^t:(member Append: _ -> 't)(a, x))let s = System.Text.StringBuilder()s << 1 << 2 << 'a'
The existing way of approaching this problem in F# is ...
Seperate the line by the oprand types
let inline(<<) a x =(^t:(member Append: _ -> 't)(a, x))let s = System.Text.StringBuilder()s << 1 << 2s << 'a'
Pros and Cons
The advantages of making this adjustment to F# are make the language consistent
The disadvantages of making this adjustment to F# are no
Extra information
Estimated cost (XS, S, M, L, XL, XXL): Maybe S?
Related suggestions: (put links to related suggestions here)
Affidavit (please submit!)
Please tick these items by placing a cross in the box:
This is not a question (e.g. like one you might ask on StackOverflow) and I have searched StackOverflow for discussions of this issue
This is a language change and not purely a tooling change (e.g. compiler bug, editor support, warning/error messages, new warning, non-breaking optimisation) belonging to the compiler and tooling repository
This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it
This is not a breaking change to the F# language design
I or my company would be willing to help implement and/or test this
For Readers
If you would like to see this issue implemented, please click the 👍 emoji on this issue. These counts are used to generally order the suggestions by engagement.
The text was updated successfully, but these errors were encountered:
It seems type checking fixes the type of the Append member of the << operator to int -> StringBuilder once it sees s << 1.
I guess that, theoretically, this could be kept open (allowing for member overloads). But then we might run into the Swift problem that was discussed on the Discord tech channel just two days ago, namely exploding (worst case: exponential) type checking effort.
I think this is a bug in the operator typechecking, we did have a few more reported recently when it comes to chaining of operators on the same line.
Note that in this case, neither parens nor duplicate function resolve the bug here, the same issue remains:
let inline (<<) a x =
(^t: (member Append: 'a -> 't) (a, x))
let inline (<<<) a x =
(^t: (member Append: 'b -> 't) (a, x))
let s = System.Text.StringBuilder()
let res1 = ( s << 1 ) <<< 'c'
FS0001 This expression was expected to have type
'int'
but here has type
'char'
I propose we allow writing an infix expression with not the same oprand type
(I do not know how to exactly explain it but it is something like this:
The existing way of approaching this problem in F# is ...
Seperate the line by the oprand types
Pros and Cons
The advantages of making this adjustment to F# are make the language consistent
The disadvantages of making this adjustment to F# are no
Extra information
Estimated cost (XS, S, M, L, XL, XXL): Maybe S?
Related suggestions: (put links to related suggestions here)
Affidavit (please submit!)
Please tick these items by placing a cross in the box:
Please tick all that apply:
For Readers
If you would like to see this issue implemented, please click the 👍 emoji on this issue. These counts are used to generally order the suggestions by engagement.
The text was updated successfully, but these errors were encountered: