Don Syme

My feedback

  1. 3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →

    This is approved for inclusion in a future release of F# subject to completion of an RFC and implementation.

    An RFC can be submitted to https://github.com/fsharp/FSharpLangDesign/tree/master/RFCs

    A pull request to implement this feature will be necessary and we encourage contributors to submit one with adequate design detail and testing to http://github.com/Microsoft/visualfsharp.

    Discussion of the particular version for this to be included in can be made once an implementation is available.

    Don Syme commented  · 

    I'm changing this to be marked as "approved". This means someone can propose a PR for the issue. PRs should be submitted to http://github.com/Microsoft/visualfsharp.

    Don Syme commented  · 

    This is not something I see as a priority (because there is an adequate way of working around the problem), but a pull request (with adequate testing etc.) that implements this could well be accepted, assuming no gotchas are found along the way.

  2. 10 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 

    My intuition would be to make this an F#-specific feature, where the F# compiler inserts the appropriate code at the callsite, and doesn't generate an actual new member in the .NET IL.

    That is, instead of auto-generating the actual extension member.

    Don Syme commented  · 

    The CallByInstance attribute proposal is very interesting. I've not seen that suggested before. It would, I think, be fairly simple to implement, with many similarities to the existing extension member implementation.

  3. 6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 

    I'm not certain, but does this work?

    type C() =
    [<DefaultValue>]
    val mutable Records: DbSet<RecType>

    ??

  4. 22 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 

    Oh I see, you mean a sort of mixin of Position into Sprite, e.g. "include Position"

    There are zillions of issues associated with this - e.g. what about subtyping? what about members on "Position"? Would Position have to be a struct?

    I'd like to see more examples of the utility of this.

  5. 20 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme shared this idea  · 
  6. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 

    While tempting, the problem is that type checking of a script would not detect these and so the static type checking of the script would not be possible.

  7. 23 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 

    As an aside, we looked at implementing this in F# 2.0 and it seems that it became surprisingly hard very quickly. I can't quite remember the details though.

  8. 5 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 

    One approach to this would be to add an OnException combinatory accepting a pair of functions. Likewise an Async.OnException.

    Don Syme commented  · 

    My inclination is that we won't do this in F#. I can see the use cases though - are there really no other ways to achieve this in .NET, e.g. by calling a library function with two lambdas?

  9. 10 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    7 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 

    In balance I think this is a reasonable suggestion and will mark it approved-in-principle

    Alternatively we could implement IReadOnlyCollection https://msdn.microsoft.com/en-us/library/hh881542(v=vs.110).aspx now that FSharp.Core 4.4.0.0+ target .NET 4.5 and .NET 4.0 is old history.

    Don Syme commented  · 

    Re this:

    > Also worth noting that the F# runtime is allowed to cheat and mutate lists ...

    FSharp.Core does this but only before list objects escape back to user code. (in any case it's not relevant to the issue under discussion here, just mentioning this in case people were wondering)

  10. 17 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 

    Strucutral subtyping is hard to implement within the constraints of the .NET type system. Any implementation would effectively have to erase to property bags at compile time. See the discussion here for example: http://fslang.uservoice.com/forums/245727-f-language/suggestions/9633858-structural-extensible-records-like-elm-concrete. This representation would also not work particularly well with .NET reflection.

    How bad is this? Well, for normal F# use it is quite bad. But for lower-performance information-representation scenarios it may not too bad.

    I'll leave this open as a general placeholder for votes on "better structural subtyping"

  11. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 

    Yes, it looks reasonable to be more flexible here. I will mark this as approved-in-principle

  12. 39 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    29 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 

    Jus to mention that I don't see anything fundamentally "non-F#" about optionally describing file dependencies explicitly within files - indeed we already do this for F# scripting using ``#load``. The file ordering would still exist.

    See http://fslang.uservoice.com/forums/245727-f-language/suggestions/10276974-allow-the-compiler-to-take-source-code-files-in-an for example

    Don Syme commented  · 

    See also http://fslang.uservoice.com/forums/245727-f-language/suggestions/10276974-allow-the-compiler-to-take-source-code-files-in-an which suggests

    open "Helpers.fs"

    or

    #requires "Helpers.fs"

    or

    #load "Helpers.fs" (which already describes dependencies in scripts)

    Note that F# scripts already have syntactic description of non-cyclic dependencies through #load. So a file ordering inferred from syntax is already part of the F# programming model, at least for scripting.

  13. 7 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  3 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme supported this idea  · 
    Don Syme commented  · 

    Other suggestions have been

    #requires "Helpers.fs"

    or

    #load "Helpers.fs" (which already describes dependencies in scripts)

    See also http://fslang.uservoice.com/forums/245727-f-language/suggestions/6323146-describe-dependencies-between-files-by-extending

  14. 215 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  18 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 

    See also this suggestion on StructTuple compatible with C# tuples: http://fslang.uservoice.com/forums/245727-f-language/suggestions/6148669-add-support-for-structtuple

    Don Syme commented  · 
  15. 168 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    15 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 
    Don Syme commented  · 

    On the specific question of "{ a with B.C = d }"... One possibility would be to give a semantics to this as follows:

    { a with ...; b.c = d } --> { a with b = { a.b with c = d}; ...}

    In addition, we could also allow "setting" properties which are not record-defined properties, e.g.

    { a with ...; b = c } --> { a with ... }._set_b(c)

    With these two rules we would have:

    { a with b.g = c; d = e } --> a._set_b(a.b._set_g(c))._set_d(e)

    where "a" can be any kind of object as long as it has _set_b and _set_b "functional property setters". The naming _set_b could be discussed.

    This is a fairly simple language feature which could be of some help, and would also address the "use record 'with' syntax on non-record types" request (https://fslang.uservoice.com/forums/245727-f-language/suggestions/6420709-allow-record-like-obj-with-newvals-syntax-for)

  16. 3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 
  17. 11 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 

    This should really go in the Visual Studio Tools user voice. But it's important to do, we should just get it done :)

  18. 10 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 

    Wallace - it's a typo I think.

  19. 31 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 

    Yes, this should I suppose be implemented to match the corresponding C# feature, since static classes will begin to be more common coming from the C# world.

  20. 29 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  F# Language  ·  Flag idea as inappropriate…  ·  Admin →
    Don Syme commented  · 

    I think this is totally reasonable, marking it as approved-in-principle.

    Note also that a naked type alias can imply multiple constraints, giving a way to name collections of constraints

    https://gist.github.com/dsyme/bfed2eed788c7ba58ccc

← Previous 1 3 4

Feedback and Knowledge Base