{"action":"created","issue":{"url":"https://api.github.com/repos/dotnet/roslyn/issues/5023","repository_url":"https://api.github.com/repos/dotnet/roslyn","labels_url":"https://api.github.com/repos/dotnet/roslyn/issues/5023/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/roslyn/issues/5023/comments","events_url":"https://api.github.com/repos/dotnet/roslyn/issues/5023/events","html_url":"https://github.com/dotnet/roslyn/issues/5023","id":104979068,"number":5023,"title":"REQUEST:  Pattern matching/better type inferencing with generics.","user":{"login":"TonyValenti","id":13609558,"avatar_url":"https://avatars.githubusercontent.com/u/13609558?v=3","gravatar_id":"","url":"https://api.github.com/users/TonyValenti","html_url":"https://github.com/TonyValenti","followers_url":"https://api.github.com/users/TonyValenti/followers","following_url":"https://api.github.com/users/TonyValenti/following{/other_user}","gists_url":"https://api.github.com/users/TonyValenti/gists{/gist_id}","starred_url":"https://api.github.com/users/TonyValenti/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/TonyValenti/subscriptions","organizations_url":"https://api.github.com/users/TonyValenti/orgs","repos_url":"https://api.github.com/users/TonyValenti/repos","events_url":"https://api.github.com/users/TonyValenti/events{/privacy}","received_events_url":"https://api.github.com/users/TonyValenti/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/dotnet/roslyn/labels/4%20-%20In%20Review","name":"4 - In Review","color":"CCCCCC"},{"url":"https://api.github.com/repos/dotnet/roslyn/labels/Area-Language%20Design","name":"Area-Language Design","color":"5319e7"},{"url":"https://api.github.com/repos/dotnet/roslyn/labels/Feature%20Request","name":"Feature Request","color":"fc2929"}],"state":"open","locked":false,"assignee":{"login":"gafter","id":3804346,"avatar_url":"https://avatars.githubusercontent.com/u/3804346?v=3","gravatar_id":"","url":"https://api.github.com/users/gafter","html_url":"https://github.com/gafter","followers_url":"https://api.github.com/users/gafter/followers","following_url":"https://api.github.com/users/gafter/following{/other_user}","gists_url":"https://api.github.com/users/gafter/gists{/gist_id}","starred_url":"https://api.github.com/users/gafter/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gafter/subscriptions","organizations_url":"https://api.github.com/users/gafter/orgs","repos_url":"https://api.github.com/users/gafter/repos","events_url":"https://api.github.com/users/gafter/events{/privacy}","received_events_url":"https://api.github.com/users/gafter/received_events","type":"User","site_admin":false},"milestone":null,"comments":27,"created_at":"2015-09-04T22:15:15Z","updated_at":"2016-06-17T05:17:15Z","closed_at":null,"body":"Hi Roslyn Team:\r\nWhen I was reading one of the feature requests from earlier:\r\nhttps://github.com/dotnet/roslyn/issues/2212#issuecomment-137754530\r\n\r\nIt made me think of something I have really been wanting as of late:\r\n\r\nPattern matching/better type inferencing with generics.\r\n\r\nToday I can write code like this:\r\n```\r\n        private static void Foo<T, X>(T Object) where T : IEnumerable<X>, IComparable<X> {\r\n            //Do Something\r\n        }\r\n\r\n        private class MyClass : IComparable<String>, IEnumerable<String> {\r\n            int IComparable<string>.CompareTo(string other) {\r\n                throw new NotImplementedException();\r\n            }\r\n\r\n            IEnumerator IEnumerable.GetEnumerator() {\r\n                throw new NotImplementedException();\r\n            }\r\n\r\n            IEnumerator<string> IEnumerable<string>.GetEnumerator() {\r\n                throw new NotImplementedException();\r\n            }\r\n        }\r\n\r\n        private static void CallMyFunction() {\r\n            var C = new MyClass();\r\n\r\n            Foo<MyClass, String>(C);\r\n        }\r\n```\r\n\r\nThere is nastiness is in how I have to call the function.\r\n```\r\n        private static void CallMyFunction() {\r\n            var C = new MyClass();\r\n\r\n            Foo<MyClass, String>(C);\r\n        }\r\n```\r\n\r\nIn this example, I feel as though Foo should automatically figure out the type parameters and I should be able to call the method as follows:\r\n```\r\n        private static void CallMyFunction() {\r\n            var C = new MyClass();\r\n\r\n            Foo(C);\r\n        }\r\n```\r\n\r\n\r\n "},"comment":{"url":"https://api.github.com/repos/dotnet/roslyn/issues/comments/226682500","html_url":"https://github.com/dotnet/roslyn/issues/5023#issuecomment-226682500","issue_url":"https://api.github.com/repos/dotnet/roslyn/issues/5023","id":226682500,"user":{"login":"HellBrick","id":3703722,"avatar_url":"https://avatars.githubusercontent.com/u/3703722?v=3","gravatar_id":"","url":"https://api.github.com/users/HellBrick","html_url":"https://github.com/HellBrick","followers_url":"https://api.github.com/users/HellBrick/followers","following_url":"https://api.github.com/users/HellBrick/following{/other_user}","gists_url":"https://api.github.com/users/HellBrick/gists{/gist_id}","starred_url":"https://api.github.com/users/HellBrick/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/HellBrick/subscriptions","organizations_url":"https://api.github.com/users/HellBrick/orgs","repos_url":"https://api.github.com/users/HellBrick/repos","events_url":"https://api.github.com/users/HellBrick/events{/privacy}","received_events_url":"https://api.github.com/users/HellBrick/received_events","type":"User","site_admin":false},"created_at":"2016-06-17T05:17:15Z","updated_at":"2016-06-17T05:17:15Z","body":">However, in cases that a tool wouldn't be feasible for whatever reason *(and in all honesty I don't think that there should be a reason not to change it but still)*, would you rather not have it at all?\r\n\r\nIf we're talking about the breaking changes in general, then I'd say it depends on the discoverability of the breaks. If the code just stops compiling after an upgrade, that's okay: you have a clear error and a pretty good idea how to fix it. But some breaking changes are next to impossible to detect manually, even if they are properly documented and understood. The inference changes caused by the current issue is a good example of that. Combing though all the overload calls that could have changed their behavior after recompiling is very difficult and error-prone even if you know the codebase well. So I think it wouldn't be nice to ship such a feature without an automatic way to find the breaks.\r\n\r\nI don't think the tool is too difficult to write, though. Even though designing a proper upgrade path that provides a nice user experience across all possible IDEs and console compilers could be tricky, writing a simple Roslyn analyzer + code fix per a breaking change seems quite possible."}}
{"actor":{"display_login":"HellBrick"}}