opened
heejaechang
username_0
```csharp
public void Test()
        {
            ValueTuple<string, int> a = ("a", 1);
            ValueTuple<string, int> a1;

            if (a is ValueTuple<string, int> c1)
            {
                a1 = c1;
            }

            Tuple<string, int> t = new Tuple<string, int>("a", 1);
            Tuple<string, int> t1;

            if (t is Tuple<string, int> t2)
            {
                t1 = t2;
            }
        }
```

FAR on ValueTuple returns nothing, but FAR on Tuple returns right references.

looks like FAR is not updated to handle ValueTuple case.
ValueTuple is not supported in FAR
issue
created
heejaechang
username_0
@username_1 can there be any reason supporting ValueTuple in FAR hard?
comment
created
jcouv
username_1
The symbol for representing tuples and `ValueTuple` instances is not a plain `NamedTypeSymbol`, it is a `TupleTypeSymbol` which is a wrapper around a `NamedTypeSymbol`.
That's why FAR behaves differently on `System.ValueTuple`/tuple than it does on `System.Tuple`.

My sense is that it shouldn't be too hard to add support in FAR. But it also doesn't seem too important.

For `System.ValueTuple`, I don't think many people would write that.
For the tuple syntax, that is what I expect people to use, but I don't think it is crucial for FAR/GoToDefinition to work on that syntax. For comparison, you can use FAR/GoToDefinition on `System.Nullable<int>`, but not on the short syntax (`int?`).
Another indication is that we didn't get reports on that.
comment
created
heejaechang
username_0
@username_1 thank you for the explanation. sure I dont think it is urgent either. tagging @jinujoseph
comment
created
CyrusNajmabadi
username_2
This was considered, but not implemented, due to too many open questions about what this should mean.  For example, if a user is doing FAR on `(a: 1, b: 2)` should they only find other tuples with those names?  Or could they find `(c: 1, d: 2)` as well?

For the most part, the IDE does not distinguish `ValueTuple<...>` from `(...)`.  So the choice to not do anything for `(...)` extends to `ValueTuple<...>` as well.
comment
created
heejaechang
username_0
if it is a design question then let me tag @kendrahavens 

for me, since we already doesn't distinguish List<string> with List<int> or Tuple<int, string> with Tuple<string, string>, I am not sure why we should do differently for ValueTuple. 

also, for syntactic sugar (...) case, our FAR already doesn't show "var" in FAR as well even if one can initiate FAR from "var". and I am pretty sure both get bound to same type. so since we already does this kind of thing, I think it is fine us not including (...) in ValueTuple case as well.
comment
created
CyrusNajmabadi
username_2
Right.  Which is why we didn't bother.  Because we didn't want to make it seem as if we supported it, only to fail to actually support it.

The situation now is: this is not supported.

Being not supported is easy to explain.  It's consistent.   If you partially support, then you've made a less understandable and more confusing situation for users. 


As i already mentioned, this was discussed and we went through these points then.  I'm not sure how/if anything has changed since the original language feature was added and we did the entire IDE pass in terms of how it should behave.  Do you feel like anything has come up to overturn those decisions?
comment
created
CyrusNajmabadi
username_2
We drove the decisions here based on what we thought would be an acceptable user experience, and then if we could provide that experience.  When we found no suitable solution, we scrapped things.  I don't want us to just do "something" just because we can.  We should do it because it would be the right thing to do for customers.
comment