-
Notifications
You must be signed in to change notification settings - Fork 4k
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
C# 7 Work List of Features #2136
Comments
What has happened to variable declaration expressions (which almost made it into C# 6) and the semicolon operator? |
Yeah. Declaration expressions was one feature I was really looking forward to in C# 6. I hope they're not dropped for good. |
What does that point mean? Searching for "supersedes" in the issues only returns this one. :) |
Is there any possibility that it will be released before the next version of Visual Studio? Waiting for two years to get all those awesome features would make me sad (although I have no idea about the complexity of the work). PS: TypeScript seems to have lots of minor versions released. |
@MadsTorgersen, I updated the description with some more proposal #s. We should probably separate out from "Safe fixed-size buffers" the ability to use custom types (rather than the small set of primitives allowed today) in fixed-size buffers. That's separate from being able to use fixed-size buffers in safe structs, but we lumped them together when discussing how we probably wouldn't get to "safe fixed-size buffers". What about the Nothing / DoesNotReturn feature? |
Deterministic disposal feature is mentioned both in "Some interest" bucket and "Probably never" bucket (as Destructible types). Having link to same proposal I suppose they both refer to the same thing. |
@stepanbenes, I believe what Mads is trying to convey is that the specific solution called out in the proposal is something we don't intend to do as-is, but we would still like to do something to address the same problem area. |
The "Strong Interest" list is awesome. Pattern matching will be a huge addition to the language. I'm quite excited about async streams as well but I would hope that there is some room to consider About static members in an interface, I believe that the CLR already permits that. Unless I'm misinterpreting what the feature entails. You also already have CLR support for |
Quite the list when you spell it all out! I agree with nearly everything in the "Strong Interest" bucket. The "Some Interest" bucket has some good ones but also a few "meh" features listed, IMO, and is missing some good ones. Off the top of my head:
|
Also- I'm surprised readonly locals is in the "Some Interest" bucket. From the comments in the discussions it seems like there's strong interest in this, the only minor point of contention is whether to use |
I guess the features that would reduce developer errors most are:
|
@MovGP0 In my experience in enterprise web dev the predominant majority of errors are made outside of C# code - JavaScript, HTML, CSS, SQL. I wish Spartan would just support C# and some lighter XAML natively... So I guess it makes sense to focus on the features that improve language expressiveness instead. |
Your strong interest list makes me very happy. |
@seanfreiburg How would that differ from the ??-operator? |
Any thoughts on #13 (Anonymous types that implement interfaces)? Also, I think there would need to be a lot of thought given to declaration expressions before they should be "bucketed". The scoping issues from last time will need a lot of discussion. Personally, I still don't like any of the options there (especially the proposal to remove the shadowing restriction) |
@dsaf well, yes and no. you are probably right that in other languages, developers make even more errors. still, F# developers make even less errors than C# developers. so it makes sense to make C# more like F#. besides, XAML/C# in the browser was tried with Silverlight, but sadly unsuccessful. I bet the best chances are to use C#/F# to JavaScript compilers with HTML in the frontend. |
I want To have the feature providing the runtime object defination will be changed. This will help of allowing the heavy objects of class. For e.g. if we do not need all the properties at a moment, we will use one rquired object of properties and no need to define separate classes and inheritance. is it possible??. If possible plz introduce such a feature. it will be great memory saving. |
Ditto! Unfortunately it doesn't look like MS is going to open their eyes about this any time soon. |
What about support for auto generated object composition |
Sad to see declaration expressions and especially params IEnumerable go. Is there anything that was dropped in the last couple of months and where can I read about it? I checked the status page - https://roslyn.codeplex.com/wikipage?title=Language%20Feature%20Status&referringTitle=Documentation but it seems like features that were dropped were removed from the table instead of marked as dropped. |
Reference to constant parameters as in C++ would be a suggestion from me. |
Hey Mads - what about: Any idea where it fits? |
@GoEddie for practical purposes this is covered by the Tuple proposal |
I favour anonymous return types over the tuple proposal. Seems like a small change to achieve the same effect. Also strong interest for Declaration expressions. |
@gdefraiteur If that's what you want to propose I suggest creating a new issue. These comments aren't tracked for consideration. There is already #186, but I don't know that I see a proposal dealing with |
@gdefraiteur we are no longer soliciting ideas for new features for C# 7. |
@gafter Started on a C# 8 list yet? |
@yaakov-h Not really, though if we did have a corresponding list for C# 8, that would not be the place to make proposals. |
@gafter Is https://github.com/dotnet/roslyn/blob/master/docs/Language%20Feature%20Status.md updated to reflect the current plan/roadmap/status? |
We don't yet have plans for future releases. |
@gafter |
@ygc369 I'd not expect that until C# 7 is shipped. They're pretty busy. =) |
And C# 7.1. And C# 7.2..... |
We've discussed so many ways to improve performance, but C#7 only implement few of them. This is very disappointing. C# is a "beautiful" language, the only lack is performance, especially about GC. |
GC is a very outdated concept. .NET needs to move to Automatic Reference Counting (as did Objective-C / Swift). It has all the programming simplicity and safety benefits while also having immediate deallocation / performance benefits. It's hard to say whether C# will EVER be able to move over to a different/faster memory model, whether GC is embedded far too deep to ever be replaced. Wouldn't bank on it. |
@marchy Been there, done that. ARC means manual reference cycle breaking, and a lot of attention to object lifetime everywhere. Especially nasty is this with lambdas ("week self" for access to properties in lambdas, anyone wants?). This will silently make virtually all the existing code leaky and therefore invalid. I bet that the "improvement" you are proposing will not be accepted by both the language design team and community. |
@vladd thanks a lot for that. Yes, there does mean people need awareness of memory. Deciding which component affects which other one is extremely important and does NOT go away in GC scenarios. We spun up specialized, senior teams on C# to chase memory leaks on .NET, particularly because they are that much more hidden and hard to discover when awareness by teams is not had at all (event subscriptions, callback patterns that hold strong references to object). "weak self" is indeed annoying and not the most elegant solution (perhaps weak should be default for lambdas on Swift), but overall for the most part it DOES just works, while coming with none of the performance & memory demands that GC-based systems provide. There's a reason Apple deprecated garbage collection on the mac after ARC came into the picture. |
@marchy You were also the one saying that C# would die if non-nullability wasn't in C#7. Asking the C# language designers to make enormous breaking changes (in the runtime rather than the language, even!) is pointless. Please look around yourself, read others' opinions, and accept the fact that you're very isolated in your position. |
@marchy For me, most of time I don't really care about exact object lifetimes. The same way as I don't care about alignment, about exact physical representation of lambdas, about overhead of storing the string length along with strings, about special magic which delegate makes to turn an instance method into something which looks like a free function, about exact shape of the state machine which compiler creates behind the scene for async methods and about a ton of different other technical details. I don't want the language to force me into considering them for each and every line of code, this would mean that my productivity as language user would drop to the native language level. If controlling some of the details matters in some special case, I do the manual solution, the language allows me that. (Or in the rare event when it doesn't allow, I implement a part of the program in native code.) (And by the way, ARC is not so innocent. Consider leaving a UI page which usually involves killing the last reference which holds a large object tree in memory—this will make the tree be destructed and run the destruction logic synchronously. This is certainly not better than GC slowly chewing on the tree in background.) |
@marchy A generational tracing GC is performant enough for the vast majority of cases in which C# is being used today (or Java for that matter), as evidenced by the fact that these languages continue to be among the most widely used. So I really doubt the .NET team is going to make the huge investment to switch to a different form of memory management any time in the foreseeable future. Personally, I'd prefer that performance improvements are focused on the lower hanging fruit that will benefit a much wider range of .NET developers, such as making LINQ (at least LINQ-to-objects) more performant with aggressive in-lining, stack allocation, loop fusion, etc. |
@timgoodman |
@timgoodman
I hope more people are interested in above ideas. |
@marchy Reference counting is as old as GC (both were from 1959). GC is not outdated for specific use like converting too large free memory to extra throughput in a system (and mostly only when the latency is not cared about); it is just an optimization being abused. Your argument about awareness still seems too weak. The fact is, there are always limited resources available to solve problems by concrete machines in reality, so people should know how to manage the onwership of resources in their solution of problems to make it logically consistent (e.g. before coding, keeping the design without any suspicous loop of dependencies to break at runtime, unless they are introduced by input of the solution). Otherwise, the solutions are inadquately designed because part of problem-specific work derserved to be solved is missing. Note there is no known "heuristic" algorithm which can beat well-trained humans for specific purpose (to resolve such inconsistency) in general, since there is no one-thing-fit-all way to tell the implementation the precise intention of the problems being solved and to guarantee it optimzed. Further, memory is just one kind of such limited resources. I'd also note automatic resource management (RAII/RRID idiom) in C++ comes far earlier than ObjC. Notably, it is not only effective on memory; it can work on other resources like locks and database connections. And it needs no compiler magic. |
@vladd The lifetime of particular objects may be trivial like alignments as implementation details, but the overall results are not similar, e.g. resources may be difficult to reclaim if you know nothing about lifetimes, which can be treated as plain leaks by users. I think being ignorant of any object lifetime by default can only work in speicific scenes, which mostly need only several DSLs rather than a general-purposed language. Otherwise, it is generally infeasible and methodologically ill-formed, unless you don't care end-users' need: because you can't estimate how many leaks the end-users can tolerate. And even all industrial users can allow this silently, system performance (also the cost on hardware) is already unnecessarily wasted a lot. To tweak the process about how to release the resources is another story after you can guarantee the deterministic behavior in time. |
An addition note on language design: modern Lisp dialects (esp. Scheme family) has better reasons to mandate unlimited extent of objects because a) objects are not bound to probable side effects on release (which is also true for many other languages) and b) both proper tail call optimization and undelimited first-class continuation are needed as killer features. I don't see any other theoretical reason to make unbounded indeterminsitic mechanism like GC required by default in a general-purposed language. |
@FrankHB |
@ygc369 what kind of stuff are you building if you are that passionate about GC optimization? Anyway I am waiting for a production-ready C# 7 release before being interested in any further features. |
The amount of script kiddies I (and a few others) deal with on helping to use Discord.Net says otherwise. Some even come in with zero understanding of programming in general, thinking that using a relatively complex lib to make a bot is a good Programming 101 exercise. |
@ygc369 怎么突然有了一股钦定的感觉呢…… 实际上我没直接提的是大部分场合引用计数都用不上。 |
The list of features for C# 7 can be found here in the csharplang repo. We're using that repository for language proposals and discussion now. |
I would like to add the alternative keywords:
instead of:
instead of:
instead of:
instead of:
instead of:
|
@lemadane commenting on a closed issue is not likely to get anything done. I suggest you look to see if there are any issues suggesting any of these things, and comment there, or open a new issue otherwise. |
@lemadane I do think there are existing issues covering most of your suggestions. |
(revision circa April 26 2016, clarifying edit June 14, 2016)
This is a list of features are looking at for C# 7, roughly categorized according to our current level of interest and estimated plausibility.
Please don't infer anything about the final shape of C# 7 (or future versions). The list is a tracking mechanism for work, not a description of the outcome. We have a long way to go yet!
Each bucket is in no particular order. I'll try to think of a more systematic way of cross-referencing with proposals and notes, but wanted to get the list out there.
I'll keep the list updated as we look at more feature ideas and change our minds about the relative importance.
Strong interest
Some interest
Non-language
See also Language Feature Status (compiler team)
The text was updated successfully, but these errors were encountered: