Skip to content

Conversation

vasily-kirichenko
Copy link
Contributor

@vasily-kirichenko vasily-kirichenko commented Jan 18, 2017

Implementation of RFC FS-1003

Vasily Kirichenko added 5 commits January 18, 2017 16:24
Conflicts:
	src/fsharp/FSComp.txt
	src/fsharp/FSharp.Core.Unittests/SurfaceArea.Silverlight.2.0.fs
	src/fsharp/FSharp.Core.Unittests/SurfaceArea.net20.fs
	src/fsharp/PostInferenceChecks.fs
	src/fsharp/TastOps.fs
	src/fsharp/TcGlobals.fs
This reverts commit 529cc6f.
This reverts commit 223d313.

Conflicts:
	tests/fsharpqa/Source/Conformance/Expressions/DataExpressions/NameOf/E_NameOfAdditionExpr.fs
	tests/fsharpqa/Source/Conformance/Expressions/DataExpressions/NameOf/E_NameOfAppliedFunction.fs
	tests/fsharpqa/Source/Conformance/Expressions/DataExpressions/NameOf/E_NameOfAsAFunction.fs
	tests/fsharpqa/Source/Conformance/Expressions/DataExpressions/NameOf/E_NameOfDictLookup.fs
	tests/fsharpqa/Source/Conformance/Expressions/DataExpressions/NameOf/E_NameOfIntConst.fs
	tests/fsharpqa/Source/Conformance/Expressions/DataExpressions/NameOf/E_NameOfIntegerAppliedFunction.fs
	tests/fsharpqa/Source/Conformance/Expressions/DataExpressions/NameOf/E_NameOfParameterAppliedFunction.fs
	tests/fsharpqa/Source/Conformance/Expressions/DataExpressions/NameOf/E_NameOfPartiallyAppliedFunction.fs
	tests/fsharpqa/Source/Conformance/Expressions/DataExpressions/NameOf/E_NameOfStringConst.fs
	tests/fsharpqa/Source/Conformance/Expressions/DataExpressions/NameOf/E_NameOfWithPipe.fs
@forki
Copy link
Contributor

forki commented Jan 18, 2017

This looks promising. Please keep us posted about progress.

| SynExpr.LongIdent(_, LongIdentWithDots(idents, _), _, _) when not (isNil idents) ->
match expr with
// `nameof` operator
| ApplicableExpr (_, Expr.App(Expr.Const(Const.String("nameof"), _, _), _, _, _, _), _) -> // no idea really what shape we should match on here, will check in debugger
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is technically a breaking change when user-defined function nameof exists in the scope. I think it should resolve the name and only treat it as nameof operator if it it was resolved to intrinsic from FSharp.Core

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vladima thanks! Any point how to do it? :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vladima I think I've found out the solution.

@vasily-kirichenko
Copy link
Contributor Author

It works:

image

@vasily-kirichenko
Copy link
Contributor Author

vasily-kirichenko commented Jan 18, 2017

  • I think we should color it as keyword
  • I wont work at attribute application site (I guess)
  • Do we need typenameof as well?

@forki
Copy link
Contributor

forki commented Jan 18, 2017

❤️

@saul
Copy link
Contributor

saul commented Jan 18, 2017

This is really cool :)

@forki
Copy link
Contributor

forki commented Jan 19, 2017

Yeah looks much better than my original implementation. Next step would be tests for doing this in attributes.

Vasily Kirichenko added 2 commits January 19, 2017 10:32
it raises a proper error if applicated to non (Long)Ident arg
@vasily-kirichenko
Copy link
Contributor Author

@forki looks like it already works in attributes:

image

I haven't checked the generated IL though.

@smoothdeveloper
Copy link
Contributor

smoothdeveloper commented Jan 19, 2017

@vasily-kirichenko, what is the value of nameof foo in this session? is nameof returning the compiled name or the F# name when [<CompiledName>] is used?

@vasily-kirichenko
Copy link
Contributor Author

@smoothdeveloper no, it returns "foo". I think that's how it's supposed to work.

@smoothdeveloper
Copy link
Contributor

That will give some surprise for those doing reflection, but yes I agree it is expected behaviour. We will need compilednameof in the future 😃

@vasily-kirichenko
Copy link
Contributor Author

The problem: currently we can use nameof as normal function:

  • call it with pipes System.DateTime |> nameof
  • pass it to other functions let x = foo nameof

So we should restrict places where nameof can appear.

@vasily-kirichenko
Copy link
Contributor Author

The above's been fixed.

@vasily-kirichenko
Copy link
Contributor Author

All cases from the list at the bottom of the RFC https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1003-nameof-operator.md work, except the following two:

  • works with provided symbol names, i.e. generated by type providers - not checked yet
  • can be used in pattern matching - does not work:

image

  • works with type arguments, let f<'t> (x : 't) = nameof 't

image

I don't think we should support the last case at all.

@dsyme any points where to fix the case with pattern matching? I think it's quite important.

@dsyme
Copy link
Contributor

dsyme commented Jan 19, 2017

(I'm going to hold off reviewing this and the RFC until VS20117 RTM is done and dusted if that's ok)

@abelbraaksma
Copy link
Contributor

@vasily-kirichenko, well, it would have been an easy resolution for what I recently encountered with running certain tests, see #3632, but I'd understand, one swallow doesn't make it Spring (Dutch proverb ;)).

@ReedCopsey
Copy link
Contributor

The fundamental problem with this feature: nobody wants it to be implemented. We could make another round of discussion, but what’s the point?

@vasily-kirichenko That's just not true - many users (including myself) would love for this to be implemented. It's very useful in certain types of applications.

@realvictorprm
Copy link
Contributor

I consider this to be fundamental. Therefor I think there isn't any argument against implementing it.
I'm going to schedule this within the next week's.

@abelbraaksma
Copy link
Contributor

abelbraaksma commented Sep 24, 2017

@realvictorprm, I think that this PR was close to being finished by @vasily-kirichenko. I'd be interested to understand the current limitations better and why they aren't resolvable (could someone elaborate with an example perhaps?), or whether we can live with those limitations (F# has more limitations when it comes to full support of whatever C# can do).

Sometimes covering 99% of all common cases is good enough, even more so if the other 1% can be worked around. Besides, it would be a waste to see all this work gone for naught.

@forki
Copy link
Contributor

forki commented Sep 24, 2017

Look @vasily-kirichenko and myself tried to get it in (#13 and #908).

It looks like super trivial feature but it has many many edge cases. What it needs is someone who goes through all the cases and makes a list which shows what is implemented and what not. Then @dsyme can decide if it is enough

@forki
Copy link
Contributor

forki commented Sep 24, 2017

(first version is over two years old)

@dsyme
Copy link
Contributor

dsyme commented Sep 25, 2017

The fundamental problem with this feature: nobody wants it to be implemented.

This is not true

What it needs is someone who goes through all the cases and makes a list which shows what is implemented and what not. Then @dsyme can decide if it is enough

This is true

@dsyme dsyme changed the title [ RFC FS-1003 ] Nameof operator reimplementation [FS-1003] Nameof operator reimplementation Dec 1, 2017
@KevinRansom KevinRansom changed the title [FS-1003] Nameof operator reimplementation [WIP] [FS-1003] Nameof operator reimplementation Dec 7, 2017
@KevinRansom KevinRansom changed the base branch from master to dev15.6 December 7, 2017 19:18
@KevinRansom KevinRansom changed the base branch from dev15.6 to master December 7, 2017 19:19
@KevinRansom
Copy link
Contributor

@dsyme, @cartermp, @vasily-kirichenko,

I'm trying to cut down the number of inactive PR's on our repo. This seems to be quite dead. I think the best thing is to close it, and let someone emerge who wants this feature drive it to completion.

It has hung around without a concerted efforted for about 3 years now.

What do you think?

Kevin

@vasily-kirichenko
Copy link
Contributor Author

I think the best thing is to close it, and let someone emerge who wants this feature drive it to completion.

So, Microsoft does not want to drive it? Why it wanted to drive the Span feature, but does not want to do this one? Who decides?

@KevinRansom
Copy link
Contributor

@vasily-kirichenko

the span feature priority is irrelevant to this discussion.

@vasily-kirichenko
Copy link
Contributor Author

I could close this PR, as I did before, but you guys love to reopen it, so feel free to close it yourself.

@KevinRansom
Copy link
Contributor

Okay I am closing this PR.

I have created a branch:
https://github.com/Microsoft/visualfsharp/tree/nameof-operator with the changes. In case anyone wants to revive this work.

@xperiandri
Copy link
Contributor

Is this feature complete?

@slang25
Copy link

slang25 commented Feb 18, 2019

@xperiandri No, it needs reviving, rebasing, and taking over the finish line.

There's a venn diagram of

  • People with time
  • People with the incentive (i.e. this is a priority for them)
  • People with the expertise

and it's a slim intersection I believe.

@vasily-kirichenko

This comment has been minimized.

@cartermp
Copy link
Contributor

From a technical standpoint, the remaining work here is to handle:

  • Additional considerations as defined in the RFC (either with everything implemented or with some cut for specific reasons)
  • A much more complete RFC, as the current one is not satisfactory in terms of documenting the feature

@dsyme dsyme mentioned this pull request Mar 12, 2019
23 tasks
@dsyme
Copy link
Contributor

dsyme commented Mar 12, 2019

Revamped implementation at #6325

@vasily-kirichenko @forki Thank you for your work on this RFC so far.

@dsyme dsyme mentioned this pull request May 22, 2019
22 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.