-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Proposal: Simplifying Using directive statements #3668
Comments
@theunrepentantgeek. Thanks for reply and those links and I wasn't aware of those links. |
This would break basic intellisense scenarios. you would type |
It doesn't matter that your proposal only looks different, they all boil down to the same thing: A desire to improve |
I am not expecting IntelliSense should come as soon as I start typing // in between brackets we can expect IntelliSense to popup
using { } from System; And also implementation in IntelliSense its another next thing. |
In the 99% case, by the time I get to those brackets, there won't be any My IDE would show: using {| This is the same flaw that SQL-based intellisense suffers from globally, and why LINQ opens with "FROM" rather than "SELECT". This is also very similar to #1696 whilst again just bikeshedding over the exact syntax and choosing one susceptible the intellisense flaw mentioned above. |
The IntelliSense issue could be solved with something like this: using System.{ Collections.Generic, Text };
using static System.{ Console, Math };
using System.{ Linq, static Math }; (Which would also get rid of the However, I am not sure that an "improvement" of |
@Unknown6656 that
That makes them more readable and natural.
That is just an IDE feature and not a language feature. |
@yaakov-h yeah, I got your point. But IntelliSense its kinda second step but we need to think first is this is a good feature to have. |
@MCCshreyas we've had previous discussions on similar issues (some of which are linked above) around "is simplifying usings to collapse many usings from a single domain into one line" and so far it hasn't been widely agreed that this is beneficial to the language. If it boils down to syntax I'd be in favour of something like Yet regardless of the shape that the syntax takes, the underlying principles and cost/value proposition (-100 points etc.) have to be in solidly in place. If the problem of having too many usings can be solved by an IDE feature, and that feature can be widely implemented in popular IDEs (VS, VSCode, maybe Rider?) then it is much cheaper to go that route than to build a new language feature. Those can be implemented sooner and be more widely available, plus they can also apply to older syntax so nobody has to wait for C# 10.0 and .NET 6, or C# 11 and .NET 7, etc. (I am completely making up the post-5 release schedule here, the exact details are not relevant.) As for Intellisense, this is of extreme importance, and dictated the form of LINQ as I alluded to above. Compiler limitations and Intellisense limitations can easily kill a language proposal. |
Could borrow a page from Python and flip the clauses around: from System using Collections.Generic, Text; That would solve the autocomplete concerns. But, IMO, .NET namespaces aren't flat enough for that syntax to have that much benefit. Sure, you can knock out the duplication of |
I haven't been writing |
The obvious solution to that is to allow nesting in the new syntax. E.g. instead of: using System;
using System.Collections;
using System.Collections.Generic;
using System.Collections.Immutable;
using System.Text; you could have something along the lines of: using System { ., Collections { ., Generic, Immutable }, Text }; It's versatile and brief, but not very readable (when you see |
I almost never read or write the using directives directly. It's all adding via intellisense or code fixes while deep in the file, or removing via code fix from the error list. In that sense the list of using directives is doing a job similar to packages.lock.json for package restores. I never read that file either. |
If my list of usings is overly long, it's often a good indicator the type does too many things and it's time to refactor it. |
I have to point out that, for people using other mother languages, putting the outer namespace at latter is decreasing readability. |
This proposal is to try to make using the directive statement better.
using
directive statement can get huge and bigger if we are importing stuff from a bunch of namespaces and most of the time it happens that it takes half of the screen if there are moreusing
statements. And also we cannot use everything from a namespace directly like doing something likeSystem.*
which some languages support. Following is the cleaner way of doing this. This proposal is to introduce a new way of importing stuff while keeping the old one in place.As we can see above we are importing all stuff from parent
System
namespace and but still, we have to mention System every single time. I think we can make it better following this.We can also have following this for more nested namespaces.
The advantages of the above approaches are that it saves space and at the same time, it expresses that things are getting used from parent
System
namespace (1st example ) without repeating System every single time.But the next question arises that how can one use things from
System
namespace itself (likeSystem.Console
) along with above namespace. One of the approaches I am thinking about is to usethis
keyword here to reference System itself (This can be improved with a better approach for sure).We can have static imports like below one with the new syntax. If we want to make all imports as static we can have following approach.
But in below case, only
Math
class is imported statically and not theConsole
class.For aliases, we can have the following way.
So these are just my thoughts about the new approach for using directive. Again, I need to make this clear is that this approach is the addition to what we currently have.
Moreover, I am always listening to community members for feedback on this. Thanks.
The text was updated successfully, but these errors were encountered: