{"action":"created","issue":{"url":"https://api.github.com/repos/rust-lang/rfcs/issues/1305","labels_url":"https://api.github.com/repos/rust-lang/rfcs/issues/1305/labels{/name}","comments_url":"https://api.github.com/repos/rust-lang/rfcs/issues/1305/comments","events_url":"https://api.github.com/repos/rust-lang/rfcs/issues/1305/events","html_url":"https://github.com/rust-lang/rfcs/pull/1305","id":109638386,"number":1305,"title":"Abstract output type parameters","user":{"login":"Kimundi","id":2903206,"avatar_url":"https://avatars.githubusercontent.com/u/2903206?v=3","gravatar_id":"","url":"https://api.github.com/users/Kimundi","html_url":"https://github.com/Kimundi","followers_url":"https://api.github.com/users/Kimundi/followers","following_url":"https://api.github.com/users/Kimundi/following{/other_user}","gists_url":"https://api.github.com/users/Kimundi/gists{/gist_id}","starred_url":"https://api.github.com/users/Kimundi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Kimundi/subscriptions","organizations_url":"https://api.github.com/users/Kimundi/orgs","repos_url":"https://api.github.com/users/Kimundi/repos","events_url":"https://api.github.com/users/Kimundi/events{/privacy}","received_events_url":"https://api.github.com/users/Kimundi/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-10-03T18:42:45Z","updated_at":"2015-10-04T04:52:12Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/rust-lang/rfcs/pulls/1305","html_url":"https://github.com/rust-lang/rfcs/pull/1305","diff_url":"https://github.com/rust-lang/rfcs/pull/1305.diff","patch_url":"https://github.com/rust-lang/rfcs/pull/1305.patch"},"body":"Enable monomorphized return types of a function that are only abstractly defined by an trait interface by introducing a new set of \"output\" generic parameters that can be defined for a function, and extending trait bounds with the concept of \"conditional\" bounds.\r\n\r\n[Rendered](https://github.com/Kimundi/rfcs/blob/function_output_type_parameters/text/0000-function_output_type_parameters.md)"},"comment":{"url":"https://api.github.com/repos/rust-lang/rfcs/issues/comments/145318014","html_url":"https://github.com/rust-lang/rfcs/pull/1305#issuecomment-145318014","issue_url":"https://api.github.com/repos/rust-lang/rfcs/issues/1305","id":145318014,"user":{"login":"mitchmindtree","id":4587373,"avatar_url":"https://avatars.githubusercontent.com/u/4587373?v=3","gravatar_id":"","url":"https://api.github.com/users/mitchmindtree","html_url":"https://github.com/mitchmindtree","followers_url":"https://api.github.com/users/mitchmindtree/followers","following_url":"https://api.github.com/users/mitchmindtree/following{/other_user}","gists_url":"https://api.github.com/users/mitchmindtree/gists{/gist_id}","starred_url":"https://api.github.com/users/mitchmindtree/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mitchmindtree/subscriptions","organizations_url":"https://api.github.com/users/mitchmindtree/orgs","repos_url":"https://api.github.com/users/mitchmindtree/repos","events_url":"https://api.github.com/users/mitchmindtree/events{/privacy}","received_events_url":"https://api.github.com/users/mitchmindtree/received_events","type":"User","site_admin":false},"created_at":"2015-10-04T04:52:11Z","updated_at":"2015-10-04T04:52:11Z","body":"Thanks for taking the time to write this up @Kimundi :)\r\n\r\nA few things that came to mind:\r\n\r\n- I find myself feeling similarly to @glaebhoerl and @P1start in that this seems to be introducing a lot of stuff for one RFC - it could almost be broken up into several RFCs?\r\n    - `abstract type`\r\n    - anonymised generics for function return types\r\n    - sugar for generics\r\n\r\n- I'm unsure I understand the purpose of the assignment of `()` in the abstract type example:\r\n```rust\r\n// Could this:\r\nabstract type Foo: Clone = ();\r\n\r\n// possibly just be this?\r\nabstract type Foo: Clone;\r\n```\r\n\r\n- The sugar section might be prone to a lot of bike-shedding and might swamp the comments a little, especially as it is not just sugar for the new feature but also for existing generics - perhaps it may have been a little cleaner to say \"here are some sugar ideas for the new feature, here's how they may also apply to existing generics, but all of this can be properly discussed further at a later point in time\"? Though I guess it is necessary to at least consider the possibilities in some detail to determine the feasibility of the feature. I guess we'll see how it goes :)\r\n\r\nIn general I really like where this is going :smile_cat: The ability to talk about the anonymised return types in the same way that we can talk about existing input generics (using where clauses and taking advantage of the type param style) is a huge plus for both consistency and expressiveness :+1:"}}