{"action":"created","issue":{"url":"https://api.github.com/repos/dotnet/roslyn/issues/8127","labels_url":"https://api.github.com/repos/dotnet/roslyn/issues/8127/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/roslyn/issues/8127/comments","events_url":"https://api.github.com/repos/dotnet/roslyn/issues/8127/events","html_url":"https://github.com/dotnet/roslyn/issues/8127","id":128331939,"number":8127,"title":"Proposal: Extension Implementations","user":{"login":"alrz","id":3105979,"avatar_url":"https://avatars.githubusercontent.com/u/3105979?v=3","gravatar_id":"","url":"https://api.github.com/users/alrz","html_url":"https://github.com/alrz","followers_url":"https://api.github.com/users/alrz/followers","following_url":"https://api.github.com/users/alrz/following{/other_user}","gists_url":"https://api.github.com/users/alrz/gists{/gist_id}","starred_url":"https://api.github.com/users/alrz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alrz/subscriptions","organizations_url":"https://api.github.com/users/alrz/orgs","repos_url":"https://api.github.com/users/alrz/repos","events_url":"https://api.github.com/users/alrz/events{/privacy}","received_events_url":"https://api.github.com/users/alrz/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2016-01-23T14:42:29Z","updated_at":"2016-01-24T03:28:59Z","closed_at":null,"body":"Consider this two interfaces.\r\n```cs\r\ninterface Iterator { }\r\n\r\ninterface Iterable { \r\n  Iterator GetIterator();\r\n}\r\n```\r\nSo every class that implements `Iterator` is effectively an `Iterable`. To establish this relation, one might think of default methods:\r\n```cs\r\ninterface Iterable { \r\n\tdefault Iterator GetIterator() {\r\n\t\treturn this; // ERROR\r\n\t}\r\n}\r\n```\r\nBut this doesn't help because you can't say if the implementor is an `Iterator`. We might define the default method as generic constrained to an `Iterator`.\r\n```cs\r\ninterface Iterable { \r\n\tdefault<T> Iterator GetIterator() where T : Iterator {\r\n\t\treturn this; \r\n\t}\r\n}\r\n```\r\nBut this design is somehow flawed (you might want more default generic implementations of the same method with different constraints) and limiting (you don't always have access to `Iterable` declaration).\r\n\r\nSo you decide to declare an extension method for every `Iterator`.\r\n```cs\r\nstatic class IteratorExtensions {\r\n\tpublic Iterator GetIterator(this Iterator @this) {\r\n\t\treturn @this;\r\n\t}\r\n}\r\n```\r\n\r\nAnd now you didn't establish any relation to `Iterable` interface at all. You know that it does have a method named `GetIterator` (duck typing) but the compiler doesn't.\r\n\r\nSo, here's my solution: define an *implementation* for every type that is an `Iterator`.\r\n```cs\r\nimplement Iterable for Iterator {\r\n\tIterator GetIterator() {\r\n\t\treturn this;\r\n\t}\r\n}\r\n``` \t\r\nQ: OK, What if we have other constraints as well? A: then you might define it as a *generic implementation*,\r\n```cs\r\nimplement<T> Iterable for T where T : Iterator {\r\n\tIterator GetIterator() {\r\n\t\treturn this;\r\n\t}\r\n}\r\n```\r\n\t \r\nThis is basically Rust's syntax for implementations but as an alternative you might suggest (like #3357):\r\n\r\n```cs\r\nextend<T> T : Iterable where T : Iterator {\r\n\tIterator GetIterator() {\r\n\t\treturn this;\r\n\t}\r\n}\r\n```\r\nNote that you are actually extending *any type* that implements `Iterator` so it has to be generic. Then I'd rather stick to the first syntax for this.\r\n\r\nAnd how this would work? Via **virtual extension methods** (#258). The compiler generates a static class for extension methods on the target type (or on the constrained generic type).\r\n\r\n```cs\r\n// the former case\r\nstatic class _CompilerGeneratedName_ {\r\n\tpublic static Iterator GetIterator(this Iterator @this) {\r\n\t\treturn @this;\r\n\t}\r\n}\r\n\r\n// the latter case\r\nstatic class _CompilerGeneratedName_ {\r\n\tpublic static Iterator GetIterator<T>(this T @this) where T : Iterator {\r\n\t\treturn @this;\r\n\t}\r\n}\r\n```\r\nNote that it is possible to add members without any interface in question, e.g.\r\n```cs\r\n// in this case we probably need to consider another keyword\r\nimplement C {\r\n  void ExtensionMethodForC() { }\r\n}\r\n```\r\nThis can neatly cover the #7844 use case. Suppose we have two classes with no relation to each other.\r\n```cs\r\nclass A { public void M() { } }\r\nclass B { public void M() { } }\r\n\r\ninterface IHasM { void M(); }\r\n\r\nimplement IHasM for A { \r\n  // can be omitted due to the trivial implementation\r\n  // void M() { this.M(); }\r\n}\r\nimplement IHasM for B { }\r\n```\r\n\r\nAs discussed in the aforementioned issue, this kind of duck typing can be inferred by the compiler but it cannot be done without a high risk of breaking existing code.\r\n\r\nPS: (1) There are numerous *open* proposals regarding template/structural types, extension classes, etc, but none of them are directly related to #258 so I decided to open another one. (2) This is not about traits and zero-cost abstraction, but same syntax can be used for implementing traits for arbitrary types."},"comment":{"url":"https://api.github.com/repos/dotnet/roslyn/issues/comments/174246381","html_url":"https://github.com/dotnet/roslyn/issues/8127#issuecomment-174246381","issue_url":"https://api.github.com/repos/dotnet/roslyn/issues/8127","id":174246381,"user":{"login":"alrz","id":3105979,"avatar_url":"https://avatars.githubusercontent.com/u/3105979?v=3","gravatar_id":"","url":"https://api.github.com/users/alrz","html_url":"https://github.com/alrz","followers_url":"https://api.github.com/users/alrz/followers","following_url":"https://api.github.com/users/alrz/following{/other_user}","gists_url":"https://api.github.com/users/alrz/gists{/gist_id}","starred_url":"https://api.github.com/users/alrz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alrz/subscriptions","organizations_url":"https://api.github.com/users/alrz/orgs","repos_url":"https://api.github.com/users/alrz/repos","events_url":"https://api.github.com/users/alrz/events{/privacy}","received_events_url":"https://api.github.com/users/alrz/received_events","type":"User","site_admin":false},"created_at":"2016-01-24T03:28:59Z","updated_at":"2016-01-24T03:28:59Z","body":"@HaloFour That restriction would apply to interfaces too. I think it addresses your concerns regarding implementation and usage, but it largely depends on #258 and what it would add to the CLR."}}