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

Allow the host to make the option type non-nestable and erased #546

Open
alfonsogarciacaro opened this Issue Feb 26, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@alfonsogarciacaro

alfonsogarciacaro commented Feb 26, 2017

From @dsyme's comment here

BTW I think you should add an F# language suggestion to allow the "host" (i.e. Fable) to make the "option" type be non-nestable and erased, so 'T option would add a constraint that 'T is not an option type.

TBD

  • How the user can tell the compiler and the IDE who's the host (.NET F# compiler or Fable). At the moment, Fable only identifies itself by defining the FABLE_COMPILER constant.
  • Are there other checks that the compiler could do if it knows options will be erased? For example, forbidding things like Map<'a, 'b option> as it would cause problems with Map.tryFind; representing the result of empty Active Patterns with something else than Some () (this is a special case in Fable, as the runtime representation of both () and None is null), etc.

Estimated cost: M-L

Affadavit (must be submitted)

  • This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue

  • I have searched both open and closed suggestions on this site and believe this is not a duplicate

  • 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 would be willing to help implement and/or test this

  • I or my company would be willing to help crowdfund F# Software Foundation members to work on this

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Feb 28, 2017

Collaborator

representing the result of empty Active Patterns with something else than Some () (this is a special case in Fable, as the runtime representation of both () and None is null), etc.

I suppose the constraint is doesn't use null as a true value. That constraint would also be useful more generally in F#

• Are there other checks that the compiler could do if it knows options will be erased? For example, forbidding things like Map<'a, 'b option> as it would cause problems with Map.tryFind;

I suppose when targeting Fable the second type parameter of Map would have the constraint.

Collaborator

dsyme commented Feb 28, 2017

representing the result of empty Active Patterns with something else than Some () (this is a special case in Fable, as the runtime representation of both () and None is null), etc.

I suppose the constraint is doesn't use null as a true value. That constraint would also be useful more generally in F#

• Are there other checks that the compiler could do if it knows options will be erased? For example, forbidding things like Map<'a, 'b option> as it would cause problems with Map.tryFind;

I suppose when targeting Fable the second type parameter of Map would have the constraint.

@alfonsogarciacaro

This comment has been minimized.

Show comment
Hide comment
@alfonsogarciacaro

alfonsogarciacaro Nov 25, 2017

BTW, Fable 1.3 accepts nested options. It has now a mixed model of erased options and a Some runtime type to solve ambiguities (like nested options, unit options, etc). It may seem complicated but again it was the only way to solve some of the problems mentioned above, like optional arguments or representing TypeScript optional members.

alfonsogarciacaro commented Nov 25, 2017

BTW, Fable 1.3 accepts nested options. It has now a mixed model of erased options and a Some runtime type to solve ambiguities (like nested options, unit options, etc). It may seem complicated but again it was the only way to solve some of the problems mentioned above, like optional arguments or representing TypeScript optional members.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment