WIP: Nameof operator#13
Conversation
|
Thanks for moving this over Steffen. From: Steffen Forkmann [mailto:notifications@github.com] ThispPull request 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 Don. Small outline:
Open questions:
Related information: C#/VB spec for nameof: https://roslyn.codeplex.com/discussions/570551 Latkin: F# 4.0 triage – This PR is not being considered for F# 4.0, but will be left open for the time being to allow for community feedback. You can merge this Pull Request by running git pull https://github.com/forki/visualfsharp nameof Or view, comment on, or merge it at: Commit Summary
File Changes
Patch Links:
— |
|
Looking forward to this functionality being added at some point. I think it will be a great addition. I could really use it for some logging I'm doing right now. |
|
Could you please describe your scenario with a small code sample? |
|
This won't be in F# 4.0, and needs further work, so I suggest we "archive" this PR for now by closing it, and then revisiting it later. |
|
Could you add some sort of labels e.g. "archived", "deferred", etc. so that it is easier to track these issues? |
|
Yes, we would need an "archived" label. The feature is still in http://fslang.uservoice.com of course, which sort of acts as a root for all future feature work on the core language/library |
|
(just a small technical note: the branch should be kept in at least one repo, otherwise it might get lost after closing) |
|
"archived" it is |
|
What is the status of this feature? |
|
I created a prototype, but there are many open edge cases.
|
|
Look forward to this feature. I assume it will work also doing interop with C# code. |
|
Example usecase: let fooType = foo.GetType().DeclaringType.GetMethod(nameof(foo)) |
|
@bluemmc yes there are many usecases, but team decided against it for now. |
|
Yes, could read that it would not make it for F# 4.0 - but that is out now. What about next F# versions - has that been decided ? |
|
@KevinRansom @otawfik-ms @NumberByColors ? |
|
Would of been nice to have the open edge cases listed so that anyone interested could look at them etc. |
|
Unfortunately I can't reopen this after @latkin closed it. IIRC we had some discussion over there. It was mostly that we don't support all the positions where nameof can be used in C# (e.g. in attributes) |
|
From the discussion here you can tell that the interest inside ms is rather low ;-) |
|
Yes, unfortunately no response from the F# team. Nameof is the one of few place where C# has a strong advantage language-wise. It is highly annoying that F# still forces developers to use a string anti-pattern when referencing stuff. @dsyme Is it possible to clarify if there are any plans for Nameof support in F# ? |
|
well, i think this pr it's dead (need rebase anyway). It's a really nice feature to have, and a good base implementation by @forki |
|
Ok I will try to rebase. Then we can let it rot again. |
@forki Would be better to release something a partial fix, rather then letting it rot as you write. Hopefully the F# team can see the benefits of your contribution after a rebase and another look? |
|
i really hope not @forki, it's a really nice feature. |
|
rebased version at #908 |
merge from master
append extension methods in GetRelevantMethodsForTrait
…crete (a) Adds a parametrized [<Theory>] over the six axes (naked-generic ctor, generic extension, static generic-type member, optional-tail, paramarray-tail) proving rule #13 fires for each. Backed by a differential default-vs-preview corpus (62 snippets): every already-successful default resolution is byte-for-byte preserved under preview (20 single-applicable rows OK:A->OK:A), incomparable cases stay ambiguous (ERR->ERR), and the feature only converts FS0041 ambiguity into success (40 rows ERR->OK). Proves ground-truth #8: (a) never flips a resolution. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
…t-plan Correctness (blocking back-compat regression): moreConcreteRule (#13, preview) ran before nullableOptionalInteropRule (#14, F#5.0 default-on) and propertyOverrideRule (#15, always-on). A resolution those default-on rules settle could be silently re-decided by #13 under preview -> overload+result-type flip. Move moreConcreteRule to the END of allTiebreakRules so it only breaks ties nothing else resolved (its intended FS0041 case). Pre-dates Phase 6 (also hit generic methods); Phase 6 widened its reach to ctors/generic-type members. Reuse: paramsMentionComparableTypeVar now takes ParamData list and uses the plural freeInTypesLeftToRight instead of List.exists over the singular walk. Compactness: shared private paramDataType accessor replaces three inlined ParamData(...) destructurings across moreConcreteRule and the FS0041 explainer. Test-plan: delete two facts that duplicated matrix rows; add instance-method-generic-type matrix row; add ORPA-beats-concreteness guard and two back-compat guards proving a later shipped rule still decides successful resolutions (static + ctor). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
This pull request 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 Don.
Small outline:
Open questions:
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)