Some exotic constraints are missing corresponding signature constructs

[kbattocchi]

Constructor constraints with more than 0 arguments and member constraints with or clauses containing at least one concrete type can be generated by F# programs, but passing the --sig option to the F# compiler results in a malformed signature file because these constructs aren't part of the grammar for signatures.

For example, given this file:

let inline f() = (^t : (new : int -> ^t) 5)
let inline g t u = ((^t or ^u) : (static member (^*^) : ^t * ^u -> ^v)(t, u)) // ok
let inline h u = g 1 u // static-typars portion of inferred constraint is (int or ^u)

--sig results in a signature file like this:

//error FS0010: Unexpected symbol '(' in member signature
val inline f : unit ->  ^t when  ^t : (( .ctor ) : int ->  ^t)
val inline g :
  t: ^t -> u: ^u ->  ^v
    when ( ^t or  ^u) : (static member ( ^*^ ) :  ^t *  ^u ->  ^v)
// error FS0010: Unexpected identifier in type constraint. Expected infix operator, quote symbol or other token.
val inline h :
  u: ^a ->  ^b when (int or  ^a) : (static member ( ^*^ ) : int *  ^a ->  ^b)

but this isn't a valid signature file because the definitions of f and h have invalid syntax.

[drvink]

See also #392, #393, and this UV. Support for signatures seems to have long since stopped tracking the current state of the language, which is unfortunate particularly because there doesn't seem to be any good way of controlling module exports without them, and CLR access controls (private/internal/etc.) aren't a substitute because they're often not usable at all (e.g. The value 'doofer' was marked inline but its implementation makes use of an internal or private function which is not sufficiently accessible and similar errors).

(Apologies to Don for my being responsible for that UV, yet still not getting around to working on a patch!)

[dsyme]

@drvink There are definitely corner cases where things that can be inferred can't be written in signatures. And you're finding them :) It's entirely reasonable to eventually address these and we would welcome PRs to address them.

@kbattocchi We should track this as a UV item . Please make sure the UV item has a link here. Consider any improvements in this space pre-approved :)

@drvink Could you give more detail on " The value 'doofer' was marked inline but its implementation makes use of an internal or private function which is not sufficiently accessible " - in what cases can't you label the appropriate transitive closure of things suitably private?

[drvink]

@dsyme A lot of the time, I want to hide implementation/helper functions that users of a module would have no need or reason to call directly (as they only exist for the benefit of functions I want to export), but it's not possible to hide them because if I make the helper functions or their enclosing module anything other than public, I get that error.

[dsyme]

BTW if you're after another exotic one, try let inline f x = printfn "%d" x :) I don't think anyone has ever really noticed, but F# has a "monomorphic choices" constraint used specifically for %d and %f in printf. There is no syntax at all for this except in signature printing. There you go.

In this case, I don't think we would ever add syntax to the language for this kind of constraint - I regard it as just arising from the built-in support for printf and unless we generalize the machinery in some way we'll leave it at that (it should, however, be mentioned as a footnote in the F# language spec, which it isn't). The world doesn't fall apart if you can't use inline and %d and signatures together. However some of the above are slightly more significant.

[dsyme]

@drvink Given that you're using a lot of statically resolved constraints, then that is probably because of the F# language restriction that member trait constraints can only be satisfied by public members, though they can be satisfied by things hidden by signatures. This is a slightly separate consideration but yes, in the same general zone.

[drvink]

@dsyme I actually ran into this before I started (ab)using overloads. :) I was doing something simple like:

let inline pchar (c : char) (p : char -> char -> bool) (errstr : string) =
  satisfy (p c) <?> errstr + Char.ToString c + "'"

let inline char (c : char) = pchar c (=) "character '"
let inline notChar (c : char) = pchar c (<>) "not character '"

...and I wanted to hide pchar, but couldn't, but I didn't want to make char/notChar not inline, since they were small functions in a performance-oriented parser.

[dsyme]

Closing in favour of #393 which is being used as the master bug for all issues with --sig