New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Champion "tuple projection initializers" (C# 7.1, VB 15.3) #415

Open
jcouv opened this Issue Apr 6, 2017 · 5 comments

Comments

Projects
None yet
5 participants
@jcouv
Member

jcouv commented Apr 6, 2017

  • Proposal added infer-tuple-names.md
  • Discussed in LDM (2017-04-05)
  • Decision in LDM (and reviewed with compat council)
  • Finalized (done, rejected, inactive)
  • Spec'ed

See also #370
A working implementation is at dotnet/roslyn#18374

@jcouv jcouv added this to the 7.1 candidate milestone Apr 6, 2017

@jcouv jcouv self-assigned this Apr 6, 2017

@jcouv jcouv changed the title from Champion tuple projection initializers to Champion "tuple projection initializers" Apr 9, 2017

@gafter gafter added the Proposal label Apr 10, 2017

@NickCraver

This comment has been minimized.

Show comment
Hide comment
@NickCraver

NickCraver Apr 21, 2017

Member

Can you please fix the link in https://github.com/dotnet/roslyn/blob/master/docs/Language%20Feature%20Status.md when the proposal is added?

Member

NickCraver commented Apr 21, 2017

Can you please fix the link in https://github.com/dotnet/roslyn/blob/master/docs/Language%20Feature%20Status.md when the proposal is added?

@jcouv

This comment has been minimized.

Show comment
Hide comment
@jcouv

jcouv Apr 21, 2017

Member

@NickCraver Will do. I think the link will actually be correct, but I need to write the document.

Member

jcouv commented Apr 21, 2017

@NickCraver Will do. I think the link will actually be correct, but I need to write the document.

@gafter gafter removed the Proposal label Apr 26, 2017

@jcouv jcouv changed the title from Champion "tuple projection initializers" to Champion "tuple projection initializers" (C# 7.1, VB 15.3) Jun 5, 2017

@DavidArno

This comment has been minimized.

Show comment
Hide comment
@DavidArno

DavidArno Aug 9, 2017

@jcouv,

I have run into an issue with this feature in Preview 7.0 of VS2017 Update 3. Consider the following example code:

public static void Foo()
{
    (T1, T2) Bar<T1, T2>((T1, T2) value) => value;

    var tuple = (a:1, b:2);
    var newTuple = Bar(tuple);
    var a = newTuple.a;
}

I get an error, "(int, int)' does not contain a definition for 'a' and no extension method 'a' accepting a first argument of type '(int, int)' could be found..." on the last line.

When it comes to generics, this tuple name inference appears to be limited to having to express the whole tuple as, eg T. If I change the code to:

public static void Foo()
{
    T Bar<T>(T value) => value;

    var tuple = (a:1, b:2);
    var newTuple = Bar(tuple);
    var a = newTuple.a;
}

then the code compiles. But then, my Bar isn't restricted to a two item tuple; it'll take any type. As ValueTuple<T1, T2> is a struct, I can't constrain T using generic constraints either.

Is this a bug/oversight, or is what I want to do completely outside the scope of this new feature?

DavidArno commented Aug 9, 2017

@jcouv,

I have run into an issue with this feature in Preview 7.0 of VS2017 Update 3. Consider the following example code:

public static void Foo()
{
    (T1, T2) Bar<T1, T2>((T1, T2) value) => value;

    var tuple = (a:1, b:2);
    var newTuple = Bar(tuple);
    var a = newTuple.a;
}

I get an error, "(int, int)' does not contain a definition for 'a' and no extension method 'a' accepting a first argument of type '(int, int)' could be found..." on the last line.

When it comes to generics, this tuple name inference appears to be limited to having to express the whole tuple as, eg T. If I change the code to:

public static void Foo()
{
    T Bar<T>(T value) => value;

    var tuple = (a:1, b:2);
    var newTuple = Bar(tuple);
    var a = newTuple.a;
}

then the code compiles. But then, my Bar isn't restricted to a two item tuple; it'll take any type. As ValueTuple<T1, T2> is a struct, I can't constrain T using generic constraints either.

Is this a bug/oversight, or is what I want to do completely outside the scope of this new feature?

@HaloFour

This comment has been minimized.

Show comment
Hide comment
@HaloFour

HaloFour Aug 9, 2017

Contributor

@DavidArno

I think that behavior is correct. In your first example Bar is returning a new unnamed tuple so it doesn't follow that the names would carry over through the individual generic type arguments. Bar could be defined to instead return (T1 a, T2 b) instead. In the second example the entire generic type argument T could be determined to be (int a, int b) so the names can carry over.

Contributor

HaloFour commented Aug 9, 2017

@DavidArno

I think that behavior is correct. In your first example Bar is returning a new unnamed tuple so it doesn't follow that the names would carry over through the individual generic type arguments. Bar could be defined to instead return (T1 a, T2 b) instead. In the second example the entire generic type argument T could be determined to be (int a, int b) so the names can carry over.

@DavidArno

This comment has been minimized.

Show comment
Hide comment
@DavidArno

DavidArno Aug 10, 2017

@HaloFour,

I think you are right: it's not a bug. It's a (very necessary, for me at least) extension to this feature. As it stands, if I method-chain with T being substituted with (x, y), (x, y) is available throughout the fluent expression. If I method-chain with (T1, T2) being substituted with (x, y), (x, y) is not accessible to the expression. So v7.1 is an improvement on v7, but it's not quite there yet.

I shall create a new proposal issue therefore.

DavidArno commented Aug 10, 2017

@HaloFour,

I think you are right: it's not a bug. It's a (very necessary, for me at least) extension to this feature. As it stands, if I method-chain with T being substituted with (x, y), (x, y) is available throughout the fluent expression. If I method-chain with (T1, T2) being substituted with (x, y), (x, y) is not accessible to the expression. So v7.1 is an improvement on v7, but it's not quite there yet.

I shall create a new proposal issue therefore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment