[RFC FS-1003 Discussion] nameof Operator

[enricosada]

This issue is used to track discussions of F# RFC FS-1003 - "nameof Operator". Please discuss in thread below (if necessary)

[dsyme]

I added some comments to the proposed PR here: dotnet/fsharp#908 (comment)

I'm concerned about the implementation strategy and think it should probably be done earlier in the type checker.

Some clarifications to the spec are needed

• Can nameof be used on ambiguous overloaded methods?
• Can nameof be used on properties that only have setters?
• Can nameof be used on constructors?

[thinkbeforecoding]

Since nameof is just the name, ambiguous overloaded methods still all have the same name, so it should work.
Same thing for properties with only setters.
For ctors, the question is.. What's the name of a constructor... If it's the same as the type, we can just use that.

[dsyme]

@thinkbeforecoding I believe nameof(C.M) will raise an ambiguous-overload type checking error in the current implementation if C.M is overloaded?

[forki]

I'm concerned about the implementation strategy and think it should probably be done earlier in the type checker.

@dsyme where should I try to hook it in?

[dsyme]

I think it's captured by this comment:

I believe we should reconsider the implementation of the feature and intercept nameof during type checking. Instead of checking the argument we would require that it is a long identifier and do unqualified expression name resolution on that identifier to a symbol, and then just take the name of the symbol. I believe that is more in the spirit of how the feature is intended to work.

So there would be a special case in the type checker

[forki]

Yes I got that. I was wondering if we already have a place where we pattern
match on the tast and rewrite it.
On Jun 20, 2016 2:41 PM, "Don Syme" [email protected] wrote:

I think it's captured by this comment:

I believe we should reconsider the implementation of the feature and
intercept nameof during type checking. Instead of checking the argument we
would require that it is a long identifier and do unqualified expression
name resolution on that identifier to a symbol, and then just take the name
of the symbol. I believe that is more in the spirit of how the feature is
intended to work.

So there would be a special case in the type checker

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#48 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AADgNGsbc-cTQ_di1BMsi4_XSDEjHNOTks5qNophgaJpZM4HTlfR
.

[dsyme]

Perhaps the closest is in TcFunctionApplicationThen where we look for seq { ... } before we check the argument. You could modify that to look for a special nameof value, and then apply completely different rules/restrictions for the processing of the argument.

There are also similarities with the processing of the reraise special value, which is only allowed at certain positions. But that has no special type-checking rules and its argument is processed as a normal argument.

[smoothdeveloper]

I don't see any mention of [<CompiledName("name")>] and I think this is an area which could get users in "principle of least surprise failed" (either way this would be handled I guess).

What is the expected behaviour in interaction with that attribute?

[thinkbeforecoding]

Interesting question.
The feature seems quite private to F# and does not seem to be meant for reflection purpose - at least not to get a method info from name....
So I'd say it should return the F# name, not the compiled name.

[Thorium]

Main purpose of nameof is probably some logging purposes, and it would be useful on some async scenarios when the stacktrace won't tell you all and you can't reraise. I would also vote the name in F# source code.

[Rickasaurus]

Main purpose of nameof is probably some logging purposes, and it would be useful on some async scenarios when the stacktrace won't tell you all and you can't reraise. I would also vote the name in F# source code.

I want nameof mostly for some amount of type safety in my reflection code. When the name of a type is changed I want to be able to get an error (or gui rename-update) for that change. I think ideally we would be able to just copy what C# nameof does.

[dsyme]

New implementation at dotnet/fsharp#2290

[smoothdeveloper]

@Rickasaurus comment makes me think we could also have exprTypeOf operator which returns a System.Type in reflection scenarios, does that sound like "fslang-design new issue" worthy?

[abelbraaksma]

I had some trouble understanding the whole requirements list on RFC FS-1003, would it be ok if I pulled it and add one or two examples to each bullet point for clarity?

I also noticed two other things that are either missing or deliberately not included:

• Works with both fully qualified names, global:: and unqualified names, provided they are in scope (i.e. nameof String and nameof System.String (yes, this seems obvious, but implementation details are not part of the RFC and it could've been implemented at tokenization phase).
• Works with constants (i.e., it should be allowed to create a literal)

Also, I was wondering about the first couple of bullet points. It seems to me this should work as a keyword (like if or let), after all it is resolved at compile time, but some examples suggest it can be used assigned to a function, piped to etc. I don't necessarily object to that, but is that the current train of thought of how this is supposed to be implemented, or is discussion still open?

[dzmitry-lahoda]

C# got some nice "statically" typed patterns with this. Hope F# would get that soon.

[jwosty]

I think that nameof(expr) should definitely give the name as it appears in F# source code (in the way @dsyme just showed), and that there should be a future separate compilednameof(expr). If nameof were to sometimes give the compiled name, that would back us into a design corner, where what if I want a use case where I really do want to get back "+" (from the operator) or "iter" (from one of the F# modules)? If both existed, the difference would be intuitive

[jwosty]

Also, since nameof can be used in literals, isn't it logical that it should also itself be usable as a pattern?

match x with
| nameof(foo) -> ...
| nameof(bar) -> ...

[TIHan]

@jwosty I think we have a PR that would enable that: dotnet/fsharp#8754

@dsyme What do you think of that?

[dsyme]

do we take the CompiledName or the F# name? The choice may matter in reflection cases.

The name occuring in the source

for instance members, is the creation of a throwaway object or value erased? It may not matter much for classes, but for value types you (probably) wouldn't want to have the overhead in the stack

The code inside the nameof(expr) is not executed. The expression is always replaced byu a string literal, including in quotations

[dsyme]

do we take the CompiledName or the F# name? The choice may matter in reflection cases.

The name occuring in the source

for instance members, is the creation of a throwaway object or value erased? It may not matter much for classes, but for value types you (probably) wouldn't want to have the overhead in the stack

The code inside the nameof(expr) is not executed. The expression is always replaced byu a string literal, including in quotations

[abelbraaksma]

Thanks @dsyme, that clears things up. @jwosty, you and a compelling point, maybe we should already start I om a lang suggestion for compilednameof, while our memory is still fresh (in my own situation, I see a stronger need for the latter, but that's just me).

[dsyme]

So it turns out that

let rec [<Literal>] x = nameof(x)

is way harder than I had considered.

OK, so at the moment F# doesn't support literal definitions in recurisve scopes that reference other literals in the recursive scope recursively or not "in order left to right". For example

let rec [<Literal>] x = 1
and y = x + 1

is allowed but

let rec [<Literal>] x = y+1
and y = 1

is not. This also applies to namespace rec and module rec, e.g.

module rec SomeCode =
    let [<Literal>] x = 1
    let y = x + 1

The reason for this is that supporting this requires adding an additional phase to the processing of recursive definitions where literals are computed and commited into the symbols. It also requires determining cycles in the graph of literal definitions. We don't do either of these thigns at the moment.

This means that

let rec [<Literal>] x = 1
and y = nameof(x)

is allowed but

let rec [<Literal>] x = nameof(x)

is not.

I think we should consider this an orthogonal limitations since, as I show above, it already applies to other literal definitions. There is not much likely use for let rec [<Literal>] x = nameof(x) (though I guess it might be away to define self-describing symbols without any actual string in your code, but I'm ok with not supporting that)

[TheJayMann]

I am okay with not supporting self defined constants, as it is not too difficult to work around, but would like to add that I do often use this pattern in C#.

const string MagicText = nameof(MagicText);

Works well for cases where a hard coded literal text is justified, the literal text is well self documenting, and it is being used in multiple locations. I've often used this pattern for the specifying the keys of an ASP.NET MVC TempData dictionary.

Of course, if it is not simple enough to justify the additional feature, it is simple enough to write let rec [<Literal>] MagicString = nameof(MagicString) as let [<Literal>] MagicString = "MagicString".

[dsyme]

Well you can just do

let rec MagicString = nameof(MagicString)

or

module rec MagicStrings =
    let Magic = nameof(Magic)

You just don't get to define it as [<Literal>].

We can definitely consider lifting the restriction, but it should just be dealt with orthogonally I think.

[cartermp]

The use for something like let rec [<Literal>] x = nameof(x) comes up a bit in the F# tooling for VS, and might show up in other tooling contexts where something expects a "tag" of sorts that is ultimately a string value. It's nice not to have to type out the string literals. Obviously you can do let rec x = nameof x to accomplish a similar gaol, but not a literal.

Also verifying from earlier in the thread that this works:

type X() as this =
    inherit Dictionary<string, string>()
    member val XValue = this.TryGetValue(nameof this.XValue) |> function true, x -> ValueSome x | false, _ -> ValueNone
    member val YValue = this.TryGetValue(nameof this.YValue) |> function true, y -> ValueSome y | false, _ -> ValueNone
    member val ZValue = this.TryGetValue(nameof this.ZValue) |> function true, z -> ValueSome z | false, _ -> ValueNone

[cartermp]

Should I file an issue on dotnet/fsharp for the general problem with literals? Or is that a language suggestion?

[dsyme]

Should I file an issue on dotnet/fsharp for the general problem with literals? Or is that a language suggestion?

I guess it's a language suggestion. It's pre-approved however.

[dsyme]

Note that the topic overlaps with various suggestions for extending the range of guaranteed compile-time evaluation of expressions in F#.

.NET literals are frustrating because they are so limited - and languages don't really have the option of augmenting what's allowed.

[cartermp]

Added fsharp/fslang-suggestions#889 - some of the example code in this thread actually requires another language suggestion, making your statement about overlap with other feature areas very true.

[brianrourkeboll]

Some tooling questions stemming from: dotnet/fsharp#18300 (comment)

1. What type should be resolved for the 'T of nameof : 'T -> string when it is used in an expression?

   let f (x : int) : string = nameof x

   It is currently resolved to 'a, even when there is no 'a in scope:

   

2. What about in patterns? The pattern input for the overall nameof pattern must of course always be of type string, but the symbol passed into nameof itself can have any type or no type at all:

   module M = begin end
   
   let f (x : string) = match x with nameof M -> () | _ -> ()

   M doesn't have a type; it's a module. Should 'T be resolved to string, because x is a string?

3. What about when the symbol given to nameof in a pattern does have a type?

   let f (x : string) (y : int) =
       match x with
       | nameof y -> ()
       | _ -> ()

   Should 'T be resolved to string here, because x is a string? Or should it be int, because y is an int?

CC @auduchinok, @T-Gro.

[smoothdeveloper]

Aside, would it make sense to have the tooltip to show the actual string as it will be compiled?

I understand that this is rather of a special case for the tooltip information, but I see it could be useful when the identifier given to nameof is composed or somehow special, resulting in non obvious value.

[jwosty]

@brianrourkeboll

1. What type should be resolved for the 'T of nameof : 'T -> string when it is used in an expression? ... It is currently resolved to 'a, even when there is no 'a in scope

Why wouldn't it just be actual type of the input variable? In this case int?

2. M doesn't have a type; it's a module. Should 'T be resolved to string, because x is a string?

Not string (since that's effectively the return type of nameof not the type of the input symbol), whatever the type of the symbol that's being nameof'd is. But yeah, modules would be a funny one; there's nothing sensible. I'd propose to just resolve it to unit.

3. What about when the symbol given to nameof in a pattern does have a type? ... Should 'T be resolved to string here, because x is a string? Or should it be int, because y is an int?

Again, it should just be int, no? I don't understand how string would make sense

[brianrourkeboll]

1. What type should be resolved for the 'T of nameof : 'T -> string when it is used in an expression? ... It is currently resolved to 'a, even when there is no 'a in scope

Why wouldn't it just be actual type of the input variable? In this case int?

I mean, yeah, at first glance it does seem like the type of the expression whose name is being gotten—assuming there is one—would make the most sense...

Not string (since that's effectively the return type of nameof not the type of the input symbol), whatever the type of the symbol that's being nameof'd is. But yeah, modules would be a funny one; there's nothing sensible. I'd propose to just resolve it to unit.

3. What about when the symbol given to nameof in a pattern does have a type? ... Should 'T be resolved to string here, because x is a string? Or should it be int, because y is an int?

Again, it should just be int, no? I don't understand how string would make sense

...The reason I suggest string here, though, is because string is the closest thing to the "type" a symbol—including definitely typeless things like namespaces and modules—might have.

If nameof were a normal function, then yes, of course 'T in nameof : 'T -> string should be instantiated to the type of the value passed in as _arg0. But it isn't a normal function, and the value (if any) and its type is only incidental to the name being gotten: it is the symbol whose name is being gotten, which may or may not refer to a value, and which has no type.