Allow typeof<module Module> or something equivalent

[Frassle]

I propose a mechanism is added to allow us to get the CLR type of a module as easily as it is for normal types with typeof<>.

This is to solve two recurring situations we have in our code base that we currently have to workaround.

The first is logger factory methods expect a CLR type to be passed in to set their context. We currently workaround this by declaring a private dummy types in modules so that we can do typeof.GetDeclaringType() to get the module type to pass to the logger.

The second is reflection based tests that check our api hasn't changed between builds, most of our tests just do typeof.Assembly to pass to the api checker, but projects with only modules in them have to instead Assembly.Load("Module").

Initial ideas for this are to somehow extend typeof<> to allow module names to be passed in, or via a new keyword like moduleof<>.

Pros and Cons

The advantages of making this adjustment to F# are we'll no longer need workarounds to get the CLR type of modules. This would trim a significant amount of boilerplate, and also stop new F#ers hitting this confusing limitation.

The disadvantages of making this adjustment to F# are that this may be a breaking change based on how it's decided to implement it.

Extra information

Estimated cost (XS, S, M, L, XL, XXL): S-M

Related suggestions: I found no related suggestions.

Affidavit (please submit!)

Please tick this 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
• 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.

Please tick all that apply:

• 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

[7sharp9]

I use a moduleof function that takes a quotation containing the thing you want the module of, works quite well :-). I also use expressions for propertyof methodof methoddefof eventof doing much the same.

…

On Sat, 30 Mar 2019 at 09:32, Fraser Waters ***@***.***> wrote: Allow typeof or something equivalent I propose a mechanism is added to allow us to get the CLR type of a module as easily as it is for normal types with typeof<>. This is to solve two recurring situations we have in our code base that we currently have to workaround. The first is logger factory methods expect a CLR type to be passed in to set their context. We currently workaround this by declaring a private dummy types in modules so that we can do typeof.GetDeclaringType() to get the module type to pass to the logger. The second is reflection based tests that check our api hasn't changed between builds, most of our tests just do typeof.Assembly to pass to the api checker, but projects with only modules in them have to instead Assembly.Load("Module"). Initial ideas for this are to somehow extend typeof<> to allow module names to be passed in, or via a new keyword like moduleof<>. Pros and Cons The advantages of making this adjustment to F# are we'll no longer need workarounds to get the CLR type of modules. This would trim a significant amount of boilerplate, and also stop new F#ers hitting this confusing limitation. The disadvantages of making this adjustment to F# are that this may be a breaking change based on how it's decided to implement it. Extra information Estimated cost (XS, S, M, L, XL, XXL): S-M Related suggestions: I found no related suggestions. Affidavit (please submit!) Please tick this by placing a cross in the box: - This is not a question (e.g. like one you might ask on stackoverflow <http://stackoverflow.com>) and I have searched stackoverflow for discussions of this issue - I have searched both open and closed suggestions on this site <https://github.com/fsharp/fslang-suggestions/issues> 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. Please tick all that apply: - 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 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#730>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAj7ysFF-vYPY5aAobpHkL8Z6gmUoarCks5vby9IgaJpZM4cTpWx> .

[Rickasaurus]

Yes please. I've wanted this for so long.

[7sharp9]

My code for this is in Falanx, seems to work for what I need it too, and avoids the latency of waiting for a compiler release. I can post a link...?

…

On Thu, 4 Apr 2019 at 19:04, Rick Minerich ***@***.***> wrote: Yes please. I've wanted this for so long. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#730 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAj7yvy0U4lmnAogYHtqGPvWX5LB4Gleks5vdj6egaJpZM4cTpWx> .

[Tarmil]

Of course, there's potential ambiguity if you have both a module and a type with the same full name.

A possible syntax to disambiguate could be typeof<module Foo>. In fact, we could even introduce <module Foo> as a valid syntax to pass a module as type parameter in any context. Although I doubt it would be used much for anything else than typeof.

Another solution would be to use typeof<FooModule>, but that feels like exposing a quasi-implementation detail.

[FraserWaters-GR]

@Tarmil I thought it was no longer the case that module types always ended with Module? That's only added if there's a clash with another type now isn't it?

[Tarmil]

@FraserWaters-GR More specifically, what happens is that if there's a clash, it used to be a compile error and you had to add an attribute that appends Module, and now Module is appended automatically. And if there is no clash, then Module isn't (and never was) appended automatically.

And yeah, that's why I think handling clashes with typeof<FooModule> is a worse solution than always using a different syntax for types and modules: typeof<FooModule> means you'd have to do something different depending on whether there's a clash or not. I just mentioned the possibility for completeness.

[Frassle]

Allowing "module Foo" in locations that expect a type would solve this. I guess it opens up the possibility that someone might try to declare a value of a module (i.e. let odd (x : module Foo) = ...), could it be restricted to allowed only in generic parameters that would also allow it for other reflection based methods, like things such as GetLogger<T>

[dsyme]

This seems reasonable - or more generally to use module M as a type (for which there are no values). I don't see any specific problem with this from a syntax point of view