Skip to content
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

Proposal: Declaration of anonymous type #8404

Closed
alexzhaosheng opened this issue Feb 5, 2016 · 9 comments
Closed

Proposal: Declaration of anonymous type #8404

alexzhaosheng opened this issue Feb 5, 2016 · 9 comments

Comments

@alexzhaosheng
Copy link

I really like the anonymous type in TypeScript, it is quite convenient when you are creating a type that is used just for one time.
Now the anonymous type of C# doesn't support declaration, this limits it's usage.
I would like to see something like this:

foo({int Value; string Description} arg){
    var xValue = arg.Value;
    var xDescription = arg.Description;

   //and maybe this?
  var areTheSameType = arg.GetType() == typeof({int Value; string Description}); //true
  areTheSameType = arg is {int Value; string Description}; //true
}


//call foo
foo(new {Value=123, Description="Test"}); //it works

foo(new {Value="str value", Description="Test"}); //compile error
@alexzhaosheng alexzhaosheng changed the title Proposal: declaration of anonymous type Proposal: Declaration of anonymous type Feb 5, 2016
@ufcpp
Copy link
Contributor

ufcpp commented Feb 5, 2016

This proposal may be the same as "denotable" anonymous type / Record in #98

@alexzhaosheng
Copy link
Author

Hi ufcpp,

Thanks for your information.
I failed to find the details about this "denotable anonymous type" . But it sounds like the thing that I want. Can't wait to try it.

@HaloFour
Copy link

HaloFour commented Feb 5, 2016

Exposing the type makes it no longer anonymous. Whatever that type is would have to be exposed with at least the same level of accessibility as the method itself and if for whatever reason the algorithm that has to generate the declared name for that type you would break all compiled consumers.

Also, since there is no type equivalence amongst anonymous types it wouldn't be possible to pass one from one assembly to another. Nor would typeof or is work since those facilities are provided by the CLR and according to the CLR they would be different types.

I think you'll find better utility with tuples (#347), since they'll all share the same underlying BCL structs.

@alexzhaosheng
Copy link
Author

Hi HaloFour,

Thanks for replying.
I think "Tuple" you mentioned is a better way to deal with this situation, anonymous should not be take as a normal type.

@dsaf
Copy link

dsaf commented Feb 5, 2016

Related to #3304.

@gafter
Copy link
Member

gafter commented Feb 8, 2016

Records are named types that seem to satisfy this need. For structs you could use tuples.

@alrz
Copy link
Contributor

alrz commented Feb 8, 2016

Doesn't this have type equivalency problem between the assemblies?

@neurospeech
Copy link

Using anonymous types everywhere will lead to refactoring problem. You will eventually create so many classes that could easily fit in hierarchy with base classes with least number of properties.

@gafter
Copy link
Member

gafter commented Mar 27, 2017

We are now taking language feature discussion in other repositories:

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https:/dotnet/csharplang/issues, and there is a draft spec at https:/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https:/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https:/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.


I am not moving this particular issue because I don't have confidence that the LDM would likely consider doing this. For nominal types, you may be interested in records (dotnet/csharplang#39). For structural types, you may be interesed in tuples (dotnet/csharplang#59).

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

No branches or pull requests

7 participants