{"action":"created","issue":{"url":"https://api.github.com/repos/dotnet/roslyn/issues/1898","labels_url":"https://api.github.com/repos/dotnet/roslyn/issues/1898/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/roslyn/issues/1898/comments","events_url":"https://api.github.com/repos/dotnet/roslyn/issues/1898/events","html_url":"https://github.com/dotnet/roslyn/issues/1898","id":67467047,"number":1898,"title":"C# Design Notes for Mar 24, 2015","user":{"login":"MadsTorgersen","id":6677272,"avatar_url":"https://avatars.githubusercontent.com/u/6677272?v=3","gravatar_id":"","url":"https://api.github.com/users/MadsTorgersen","html_url":"https://github.com/MadsTorgersen","followers_url":"https://api.github.com/users/MadsTorgersen/followers","following_url":"https://api.github.com/users/MadsTorgersen/following{/other_user}","gists_url":"https://api.github.com/users/MadsTorgersen/gists{/gist_id}","starred_url":"https://api.github.com/users/MadsTorgersen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MadsTorgersen/subscriptions","organizations_url":"https://api.github.com/users/MadsTorgersen/orgs","repos_url":"https://api.github.com/users/MadsTorgersen/repos","events_url":"https://api.github.com/users/MadsTorgersen/events{/privacy}","received_events_url":"https://api.github.com/users/MadsTorgersen/received_events","type":"User","site_admin":false},"labels":[{"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/Design%20Notes","name":"Design Notes","color":"fc2929"},{"url":"https://api.github.com/repos/dotnet/roslyn/labels/Language-C%23","name":"Language-C#","color":"207de5"},{"url":"https://api.github.com/repos/dotnet/roslyn/labels/Language-VB","name":"Language-VB","color":"207de5"}],"state":"open","locked":false,"assignee":{"login":"MadsTorgersen","id":6677272,"avatar_url":"https://avatars.githubusercontent.com/u/6677272?v=3","gravatar_id":"","url":"https://api.github.com/users/MadsTorgersen","html_url":"https://github.com/MadsTorgersen","followers_url":"https://api.github.com/users/MadsTorgersen/followers","following_url":"https://api.github.com/users/MadsTorgersen/following{/other_user}","gists_url":"https://api.github.com/users/MadsTorgersen/gists{/gist_id}","starred_url":"https://api.github.com/users/MadsTorgersen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MadsTorgersen/subscriptions","organizations_url":"https://api.github.com/users/MadsTorgersen/orgs","repos_url":"https://api.github.com/users/MadsTorgersen/repos","events_url":"https://api.github.com/users/MadsTorgersen/events{/privacy}","received_events_url":"https://api.github.com/users/MadsTorgersen/received_events","type":"User","site_admin":false},"milestone":{"url":"https://api.github.com/repos/dotnet/roslyn/milestones/8","html_url":"https://github.com/dotnet/roslyn/milestones/C%23%207%20and%20VB%2015","labels_url":"https://api.github.com/repos/dotnet/roslyn/milestones/8/labels","id":962632,"number":8,"title":"C# 7 and VB 15","description":"","creator":{"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},"open_issues":31,"closed_issues":1,"state":"open","created_at":"2015-02-02T23:41:34Z","updated_at":"2015-04-09T22:49:23Z","due_on":null,"closed_at":null},"comments":8,"created_at":"2015-04-09T22:49:23Z","updated_at":"2015-04-10T14:49:05Z","closed_at":null,"body":"C# Design Meeting Notes for Mar 24, 2015\r\n========================================\r\n\r\n*Quote of the Day:* If we have slicing we also need dicing!\r\n\r\n\r\nAgenda\r\n------\r\n\r\nIn this meeting we went through a number of the performance and reliability features we have discussed, to get a better reading on which ones have legs. They end up falling roughly into three categories:\r\n\r\n* Green: interesting - let's keep looking\r\n* Yellow: there's something there but this is not it\r\n* Red: probably not\r\n\r\nAs follows:\r\n\r\n1. ref returns and locals <*green*> (#118)\r\n2. readonly locals and parameters <*green*> (#115)\r\n3. Method contracts <*green*> (#119)\r\n4. Does not return <*green*> (#1226)\r\n5. Slicing <*green*> (#120)\r\n6. Lambda capture lists <*yellow - maybe attributes on lambdas*> (#117)\r\n7. Immutable types <*yellow in current form, but warrants more discussion*> (#159)\r\n8. Destructible types <*yellow - fixing deterministic disposal is interesting*> (#161)\r\n9. Move <*red*> (#160)\r\n10. Exception contracts <*red*>\r\n11. Static delegates <*red*>\r\n12. Safe fixed-size buffers in structs <*red*> (#126)\r\n\r\nSome of these were discussed again (see below), some we just reiterated our position.\r\n\r\n\r\n\r\n1. Ref returns and locals\r\n=========================\r\n\r\nAt the implementation level these would require a verifier relaxation, which would cause problems when down targeting in sandboxing scenarios. This may be fine.\r\n\r\nAt the language level, ref returns would have to be allowed on properties and indexers only if they do not have a setter. Setters and ref would be two alternative ways of allowing assignment through properties and indexers. For databinding scenarios we would need to check whether reflection would facilitate such assignment through a ref.\r\n\r\nA danger of ref returns in public APIs: say you return a ref into the underlying array of e.g. a list, and the list is grown by switching out the underlying array. Now someone can get a ref, modify the collection, follow the ref and get to the wrong place. So maybe ref returns are not a good thing on public API boundary.\r\n\r\nThere's complexity around \"safe to return\": You should only return refs that you received as parameters, or got from the heap. This leads to complexity around allowing reassignment of ref locals: how do you track whether the ref they are pointing to is \"safe to return\" or not? We'd have to either\r\n\r\n* add syntax to declare which kind the local points to (complex)\r\n* allow only one of the kinds to be assigned to locals (restrictive)\r\n* track it as best we can through flow analysis (magic) \r\n\r\nThere's complexity in how refs relate to readonly. You either can't take a ref to a readonly, or you need to be able to express a readonly ref through which assignments is illegal. The latter would need explicit representation in metadata, and ideally the verifier would enforce the difference.\r\n\r\nThis can't very well be a C# only feature, at least if it shows up in public APIs. VB and F# would need to at least know about it.\r\n\r\nThis feature would be a decent performance win for structs, but there aren't a lot of structs in the .NET ecosystem today. This is a chicken-and-egg thing: because structs need to be copied, they are often too expensive to use. So this feature could lower the cost of using structs, making them more attractive for their other benefits.\r\n\r\nEven so, we are still a bit concerned that the scenario is somewhat narrow for the complexity the feature adds. The proof will have to be in the use cases, and we're not entirely convinced about those. It would be wonderful to hear more from the community. This is also a great candidate for a prototype implementation, to allow folks to experiment with usability and performance.\r\n\r\n\r\n\r\n2. Readonly locals and parameters\r\n=================================\r\n\r\nAt the core this is a nice and useful feature. The only beef we have with it is that you sort of want to use `readonly` to keep your code safe, and you sort of don't because you're cluttering your code. The `readonly` keyword simply feels a bit too long, and it would be nice to have abbreviations at least in some places. \r\n\r\nFor instance `readonly var` could be abbreviated to `val` or `let`. Probably `val` reads better than `let` in many places, e.g. declaration expressions. We could also allow `val` as an abbreviation for `readonly` even in non-var situations. \r\n\r\nIn Swift they use `let` but it reads strange in some contexts. In Swift it's optional in parameter positions, which helps, but we couldn't have that for back compat reasons.\r\n\r\nThis is promising and we want to keep looking at it.\r\n\r\n\r\n\r\n4. Does Not Return\r\n==================\r\n\r\nIt would be useful to be able to indicate that a method will never return successfully. It can throw or loop.\r\n\r\nThe proposal is to do it as an attribute, but there would be more value if it was part of the type system. Essentially it replaces the return type, since nothing of that type is ever returned. We could call it `never`. The `never` type converts to pretty much anything.\r\n\r\nThis would allow us to add throw *expressions* in the language - their type would be `never`.\r\n\r\nHaving it in the type system allows e.g. returning `Task<never>`, so that you can indicate an async method that will only ever produce an exception, if anything.\r\n\r\nBecause of the Task example you do want to allow `never` in generics, but that means you could have generic types that unwittingly operate on never values, which is deeply strange. This needs to be thought about more.\r\n\r\nIf through nasty tricks you get to a point in the code that according to never types should not be reachable, the code should probably throw.\r\n\r\nA common usage would be helper methods to throw exceptions. But throw as an expression is the most useful thing out of this.\r\n\r\n \r\n\r\n6. Attributes on lambdas\r\n========================\r\n\r\nWhy? Guiding an analyzer, e.g. to prevent variable capture. Syntactically it might collide with XML literals in VB.\r\n\r\nWe could probably hack it in. The attribute would be emitted onto the generated method.\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/dotnet/roslyn/issues/comments/91581342","html_url":"https://github.com/dotnet/roslyn/issues/1898#issuecomment-91581342","issue_url":"https://api.github.com/repos/dotnet/roslyn/issues/1898","id":91581342,"user":{"login":"HaloFour","id":10102290,"avatar_url":"https://avatars.githubusercontent.com/u/10102290?v=3","gravatar_id":"","url":"https://api.github.com/users/HaloFour","html_url":"https://github.com/HaloFour","followers_url":"https://api.github.com/users/HaloFour/followers","following_url":"https://api.github.com/users/HaloFour/following{/other_user}","gists_url":"https://api.github.com/users/HaloFour/gists{/gist_id}","starred_url":"https://api.github.com/users/HaloFour/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/HaloFour/subscriptions","organizations_url":"https://api.github.com/users/HaloFour/orgs","repos_url":"https://api.github.com/users/HaloFour/repos","events_url":"https://api.github.com/users/HaloFour/events{/privacy}","received_events_url":"https://api.github.com/users/HaloFour/received_events","type":"User","site_admin":false},"created_at":"2015-04-10T14:49:05Z","updated_at":"2015-04-10T14:49:05Z","body":"@MgSam The following syntax works to prevent Markdown from renumbering lists:  `123\\.`\r\n\r\n2\\.  I'm also curious about how `let` reads strange.  I know that grammatically it does read differently from `var` or `val` but I think that's excusable if you read it in the context of declaring a constant.  I agree with MgSam that my preference for `let` comes from both being easily visually distinguishable from `var` as well as already existing in LINQ to perform a nearly identical purpose.\r\n\r\n3\\.  Has there been any further discussion as to how method contracts will implement failure?  The thread for #119 got pretty extensive mostly over the concept of how the contract should fail.  My opinion remains that if fail-fast is the (only) behavior and that if programmers will have to write canonical argument validation anyway that contracts will find very limited use, just like the Code Contract project it intends to replace.  Ultimately I think it should be configurable by whatever is hosting the assembly.\r\n\r\n4\\.  Considering the limited use case for this and how it would be an analyzer-only situation I don't see why a language construct would be that much more useful than just having a common attribute in the BCL.  So you save a few keystrokes a handful of times, is that worth the expense of modifying the language?\r\n\r\n5\\.  Any motion to maybe have the CLR support this?  The feature seems like it would be really limited without that support since you can't slice arrays to arrays or strings to strings without allocation/copying and having to use an interface as an intermediary makes it unusable for most of the APIs that currently exist.\r\n\r\n6\\.  Not sure what the capture list would have to do with attributes.  Wouldn't it only affect how the compiler generates the closure class?\r\n\r\n11\\.  Are \"expection contracts\" different from method contracts?"}}