intrinsic type extension across file boundries

[patrickallensimpson]

I can't for the life of me remember why it was decided that we can't have intrinsic type extensions across file boundaries?

What I want to know is why this isn't supported:

File1.fs

namespace NS

type Partial = {
    field : int
}

type Partial with
    member x.Div2 = x.field / 2

File2.fs

namespace NS

type Partial with
    member x.Div3 = x.field / 3  // you currently get the following error FS0644: Namespaces cannot contain extension members except in the same file and namespace declaration group where the type is defined. Consider using a module to hold declarations of extension members.

These would both be compiled into the same assembly and of course are in the same namespace.

Interestingly if the following code is in the same file this actually works as I would expect:

SingleFile.fs

namespace NS

type Partial = {
    field : int
}

module Mod1 =
    let p = { field = 1 }
    let pField = p.field
    let pDiv2 = p.Div2 // compilation error that Div2 doesn't exist

type Partial with
    member x.Div2 = x.field / 2

module Mod2 =
    let pDiv2' = p.Div2 // this is ok now since its available 

So I would expect that a code file that would exist between File1.fs and File2.fs shouldn't see anything defined in File2.fs. If we supported this, then we could support code gen scenarios better.

[kerams]

What I want to know is why this isn't supported:

Did you read the error message carefully, and try to do what it suggested? :)

[patrickallensimpson]

Yes I did read the error message :)

To clarify the question since you do point this out:

The point is NOT to make an extrinsic type extension. Intrinsic type extensions are compiled into the definition of the original type definition and have access to all the let (private) bindings. In the above example the Partial type actually has the Div2 as a member and could access any the let bindings.

If I do what the error message says then I'll have an extension method inside the Module that can only access public and internal fields, NOT let bindings for instance. I just found it odd that this restriction exists and am trying to understand the reasoning for it and when it occurred.

In fact, I came across some code examples recently from several years ago in which this apparently worked at one time and the author suggested this was a way of supporting the same feature as partial classes in C#.

This author was very through in other writings regarding F# concepts, and so I am assuming he tested this before writing the blog post.

I had thought this didn't work (until reading the above blog post) and this is one of the reason's I don't do intrinsic type extensions in my code bases because they don't work in an orthogonal way as I would expect.

I really don't like using a feature or explaining one to my junior staff that has a major gotcha that jumps up and bits you for no apparent reason.

And from looking at some of the compiler code base so far, it's not clear why we don't do this. Thus, the question, we must have had a reason for this decision.

:)

[kerams]

Fair enough, the distinction was lost on me.

[vzarytovskii]

It's been decided long time ago really, spec states it explicitly in 8.12:

If the type extension is in the same module or namespace declaration group as the original type definition, it is called an intrinsic extension. Members that are defined in intrinsic extensions follow the same name resolution and other language rules as members that are defined as part of the original type definition.