[WIP] F# RFC-1003 - Implementing nameof operator #908

forki · 2016-01-29T09:37:17Z

RFC: https://github.com/fsharp/FSharpLangDesign/blob/master/RFCs/FS-1003-nameof-operator.md

This is a rebased version of #13, which was moved from https://visualfsharp.codeplex.com/SourceControl/network/forks/forki/fsharp/contribution/7698 (see discussion there)

https://fslang.uservoice.com/forums/245727-f-language/suggestions/5900625-add-nameof-operator-to-follow-c-vb-update suggests we implement a "nameof" operator which is something similar to the typeof operator.

This feature was "approved in principle" by @dsyme.

Related information:

C#/VB spec for nameof: https://roslyn.codeplex.com/discussions/570551
Mads showing the nameof operator: http://channel9.msdn.com/Events/Visual-Studio/Connect-event-2014/116 (at 5:35)

Current status:

enricosada · 2016-01-29T09:40:11Z

@forki put [WIP] in the title

enricosada · 2016-01-29T09:44:05Z

src/fsharp/FSharp.Core/Linq.fs

@@ -195,7 +195,7 @@ module LeafExpressionConverter =

    let isFunctionType typ = equivHeadTypes typ (typeof<(int -> int)>)
    let getFunctionType typ = 
-        if not (isFunctionType typ) then invalidArg "typ" "cannot convert recursion except for function types"
+        if not (isFunctionType typ) then invalidArg (nameof typ) "cannot convert recursion except for function types"


i dont think we should use nameof in this pr.
Like that you cannot compile FSharp.Core with LKG compiler (i think that's used somewhere in proto)
Also that make this pr bigger than needed
The use of nameof can be an additional pr after this one is merged

yeah. I'm removing the use in FSharp.Core - that wasn't really a good idea

enricosada · 2016-01-29T09:51:52Z

btw, jenkins fails /cc @otawfik-ms @TyOverby

java.io.IOException: remote file operation failed: d:\j\workspace\Microsoft_visualfsharp\debug_windows_nt_prtest at hudson.remoting.Channel@3da6bc31:Azure0128054658: java.nio.file.AccessDeniedException: d:\j\workspace\Microsoft_visualfsharp\debug_windows_nt_prtest\debug\net40\bin\FSharp.Core.dll

enricosada · 2016-01-29T10:08:28Z

src/fsharp/FSharp.Core.Unittests/NameOfTests.fs

+    [<Test>]
+    member this.``lookup name of + operator`` () =
+        let b = nameof(+)
+        Assert.AreEqual("op_Addition",b)


That's expected behaviour for operators? i mean nameof(+) shouldnt be + ?

op_Addition is compiled name IIRC

yes, but it's what we want for nameof(+)? just asking, it make sense as op_Addition

do you have a C# compiler at hand? What's that thingy saying?

yes, let me check

and tbh it's probably never used in practice.

side question: why is "dotnet repl" starting the C# repl? Because CLR = C# language runtime?

@forki 👍 for op_Addition, can be nice to know compiled name, and i dont think it's really usefull do nameof(+)

@forki about dotnet/cli it's ok, dotnet repl run dotnet-repl-csi because default lang is c#.
No need to fight anymore for defaults, i tried with dotnet new, a nice discussion and now i think there is a nice command line api (cmd api is language agnostic, default is c# sometimes, like dotnet new or dotnet repl)

The real big boss dotnet build doesnt need a lang argument.

About default c#, i think we can live with that if the language support is ok.
So dotnet repl f# runs dotnet-repl-fsi. BTW because fsi is in path (it's near dotnet.exe), you can do just fsi
i'll implement dotnet repl lang soon (lang argument already works, we need a dotnet-repl-fsi to call fsi) . For example my dotnet new f# support got merged two days ago, but dotnet/cli is a nice repo, discussion => actions and team help a lot

@forki side answer update, now there is dotnet/cli#1118 about use a DOTNET_DEFAULT_LANGUAGE env var for dotnet new and dotnet repl.

See. Sometimes we have to ask the right questions.
On Jan 29, 2016 1:41 PM, "Enrico Sada" [email protected] wrote:

In src/fsharp/FSharp.Core.Unittests/NameOfTests.fs
#908 (comment):

member this.static class function name () =

let b = nameof(Tuple.Create)

Assert.AreEqual("Create",b)

+[]
+type OperatorNameTests() =
+

[]

member this.lookup name of typeof operator () =

let b = nameof(typeof<int>)

Assert.AreEqual("TypeOf",b)

[]

member this.lookup name of + operator () =

let b = nameof(+)

Assert.AreEqual("op_Addition",b)

@forki https://github.com/forki side answer update, now there is
dotnet/cli#1118 https://github.com/dotnet/cli/issues/1118 about use a
DOTNET_DEFAULT_LANGUAGE env var for dotnet new and dotnet repl.

—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/visualfsharp/pull/908/files#r51256391.

enricosada · 2016-01-29T10:36:31Z

add gitignore of fsharp.core in tests ( see #894 (comment) )

forki · 2016-01-29T10:39:04Z

Nah, that should be done in separate PR and applied immediately. Annoying to the max. /cc @otawfik-ms

mexx · 2016-01-29T10:54:01Z

src/fsharp/FSharp.Core.Unittests/NameOfTests.fs

+        let myFunction parameter1 = nameof parameter1
+
+        Assert.AreEqual("parameter1",myFunction "x")
+        Assert.AreEqual("parameter1",myFunction "x")


Is this second assert of any value?

We want to be really really sure here!

Guess it's merge /rebase issue from long time ago

dsyme · 2016-02-04T18:13:46Z

src/fsharp/Optimizer.fs

+        match tyargs with
+        | (typeName:TType):: _ ->
+            let name =
+                match typeName with 


Please call stripTyEqns typeName. Consider, for example, typenameof<'T> where 'T gets later instantiated to int, e.g.

let f(x:'T) = typenameof<'T>; (x = 3)

This will raise a warning that 'T can't be generalized and gets set to int, but apart from the warning the code is allowed.

Also, please consider what happens in the presence of type aliases type x = int. I assume the intended spec is that the name of the canonical representation is returned. Using stripTyEqns will achieve this.

smoothdeveloper · 2016-05-04T03:07:07Z

It would be awesome to have this revived and shipped in next language update.

I imagine there is a way to do similar thing with code quotations but a proper operator (even if it doesn't cover all the cases) is a much better option.

7sharp9 · 2016-05-05T11:00:05Z

@smoothdeveloper You can like this:

 match <@@  (Unchecked.Defaultof<MyType> : MyType.MyMethodWithIntParam<'a>(0) @@> with
 | Patterns.Call(_,mi,_) -> ...

Works well.

KevinRansom · 2016-05-26T18:08:36Z

@forki,
@dsyme,

This one I'm going to close, since it seems to have atrophied.
Please re-open if you get the time to do more work on it.

Thank you

Kevin

dsyme · 2016-05-27T11:27:57Z

@KevinRansom Let's keep open any WIP PRs that correspond to an approved F# RFC. Inactivity is OK for RFCs - they can take months or years to get through the system.

forki · 2016-06-03T07:19:59Z

I rebased this on master

AviAvni · 2016-07-03T14:35:53Z

@forki @dsyme Can I help with this?

KevinRansom · 2016-11-08T04:48:36Z

Closing

isaacabraham · 2016-11-08T06:15:25Z

Why are you closing this?

dsyme · 2016-11-09T15:42:44Z

@isaacabraham I think it's reasonable to close PRs that haven't been touched for a very long time.

The PR can definitely be resubmitted as part of F# 4.2 work, it's not lost.

It's probably on my plate to review the RFC and implementation once again. But the RFC tracks the issue for now.

bryanedds · 2016-11-29T17:37:52Z

I might like to be able to write inline functions that take the parameter that nameof receives and pass it directly along to the operator invocation. It seems like this should be possible. Is this possible with the current implementation? If not, can we consider that as a feature?

bryanedds · 2016-11-29T17:48:03Z

Actually, as it turns out, my above comment in its initial form was not very accurate (I have since altered it).

I looked at my code base, and as it turns out, I only have speculative uses for making the nameof parameter forwardable from inline functions. It wouldn't do anything for my current code base after all. Doesn't mean the capability isn't worth consideration tho, I suppose.

Apologies for the misdirection.

msftclas added the cla-already-signed label Jan 29, 2016

forki mentioned this pull request Jan 29, 2016

WIP: Nameof operator #13

Closed

forki force-pushed the nameof2 branch from 5eb214c to 2e1c9f8 Compare January 29, 2016 09:39

forki force-pushed the nameof2 branch from 2e1c9f8 to aa182ef Compare January 29, 2016 09:41

forki changed the title ~~Implementing nameof operator~~ [WIP] Implementing nameof operator Jan 29, 2016

enricosada reviewed Jan 29, 2016
View reviewed changes

forki force-pushed the nameof2 branch 4 times, most recently from afeff33 to d8f83bf Compare January 29, 2016 10:05

enricosada reviewed Jan 29, 2016
View reviewed changes

forki force-pushed the nameof2 branch from d8f83bf to faa2ec5 Compare January 29, 2016 10:16

mexx reviewed Jan 29, 2016
View reviewed changes

forki force-pushed the nameof2 branch 2 times, most recently from 25d9b98 to a40c767 Compare January 29, 2016 13:28

dsyme reviewed Feb 4, 2016
View reviewed changes

forki force-pushed the nameof2 branch from 71d5250 to 492df41 Compare February 5, 2016 11:00

KevinRansom closed this May 26, 2016

dsyme reopened this May 27, 2016

msftclas added the cla-already-signed label May 27, 2016

forki force-pushed the nameof2 branch from 492df41 to cc7a25a Compare June 3, 2016 07:18

forki force-pushed the nameof2 branch 2 times, most recently from 9ef9719 to c2b74ad Compare June 3, 2016 08:15

forki added 2 commits June 20, 2016 09:44

Implementing basic nameof and typenameof operators

130751d

Apply feedback

bd88bab

forki force-pushed the nameof2 branch from c2b74ad to bd88bab Compare June 20, 2016 07:44

dsyme changed the title ~~[WIP] Implementing nameof operator~~ [WIP] F# RFC-1003 - Implementing nameof operator Jun 21, 2016

KevinRansom closed this Nov 8, 2016

dsyme mentioned this pull request Nov 9, 2016

[WIP] RFC FS-1001 - String Interpolation #921

Closed

3 tasks

forki mentioned this pull request Sep 24, 2017

[WIP] [FS-1003] Nameof operator reimplementation #2290

Closed

[WIP] F# RFC-1003 - Implementing nameof operator #908

[WIP] F# RFC-1003 - Implementing nameof operator #908

Uh oh!

Conversation

forki commented Jan 29, 2016 • edited by dsyme Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

enricosada commented Jan 29, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

enricosada commented Jan 29, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

enricosada commented Jan 29, 2016

Uh oh!

forki commented Jan 29, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

smoothdeveloper commented May 4, 2016

Uh oh!

7sharp9 commented May 5, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

KevinRansom commented May 26, 2016

Uh oh!

dsyme commented May 27, 2016

Uh oh!

forki commented Jun 3, 2016

Uh oh!

AviAvni commented Jul 3, 2016

Uh oh!

KevinRansom commented Nov 8, 2016

Uh oh!

isaacabraham commented Nov 8, 2016

Uh oh!

dsyme commented Nov 9, 2016

Uh oh!

bryanedds commented Nov 29, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bryanedds commented Nov 29, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

forki commented Jan 29, 2016 •

edited by dsyme

Loading

7sharp9 commented May 5, 2016 •

edited

Loading

bryanedds commented Nov 29, 2016 •

edited

Loading

bryanedds commented Nov 29, 2016 •

edited

Loading