21–30 of 59 posts
C# is becoming the C++ of managed languages. I wish they would stick to a smaller set of more powerful features… like an earlier C# with hygienic macros or something.
I'd love to see a C#/.Net Standard release that was dedicated to getting rid of things. It may be less exciting in the short term, but it is well past due.
Oh wow. I do not like that "global using". It harkens to the auto-loading issues I've had with Rails. "Where was this defined? I dunno! It probably works here, though!!1" I generally don't like a random file impacting several other files. Extension methods are ... tolerated and ... "fine" but I still feel unpleasant using them. File-Scoped namespaces seem like someone's really, really tired of having nested folders a…
Doesn't really bother me, so long as the global usings are only kept to a single file. Intellisense will tell you the full namespace, then you can just see if you've got that namespace in the file you're in or in your dedicated global usings file.
I would consider this the same: Project should have a `GlobalUsings.cs` file.
Does C# have any linters available that could enforce such a conventions?
Earlier quoted context omitted.
I do not like that "global using" as well. I wonder why they added it.
Looks like they added global usings to support their implicit usings functionality. Essentially they want to save people having to put using System, System.Linq, System.Collections.Generic, and others[0] at the top of nearly every C# file. I'm of two minds: - I think they're an anti-pattern, because it creates a global scope that can get messy/annoying. - It makes a ton of sense for the implicit usings functionality,…
Ugh. So with the new method groups feature, adding a new method overload can break working code even if that code never calls the new overload.
Using the example of Console.Read from the article, in C# 9, you could do `Func read = Console.Read;`. Now, if someone adds an overload for the Read method to Console, that C# 9 code will break.
In C# 10, that doesn't change. What changes is that we don't have to specify `Func`. We can just use `var`.
C# is becoming the C++ of managed languages. I wish they would stick to a smaller set of more powerful features… like an earlier C# with hygienic macros or something.
That's basically F#. One can program just using OOP in F#, and it is much more clean and concise.
Dumb questions: why does it seem like languages always continually add features? Can a language not become "feature complete", while still improving over time?
We don't know how to make languages. We're in the Kepler stage of software development. Everyone has a different 'cosmology' to explain what's going on, we don't yet have the technology to understand what's going on, we don't have the math yet to explain what's going on, and we're just in the very beginning stages of even being able to take measurements of anything worth while. "Here's a feature" Now, will it makes c…
Every year, new words are constantly added to official dictionaries ... while old words continually fall out of favor/use.
And concepts in one language (e.g. "English" or "Rust") then get adopted/imported into another language (e.g. "French" or "Go").
Dumb questions: why does it seem like languages always continually add features? Can a language not become "feature complete", while still improving over time?
Earlier quoted context omitted.
Doesn't really bother me, so long as the global usings are only kept to a single file. Intellisense will tell you the full namespace, then you can just see if you've got that namespace in the file you're in or in your dedicated global usings file.
I thought it was generally considered good practice to put extension methods into static classes in their own file. So like `FooExtensions.cs` if you are writing extensions for the `Foo` class. I would consider this the same: Project should have a `GlobalUsings.cs` file. Does C# have any linters available that could enforce such a conventions?
https://docs.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/tu...
Oh wow. I do not like that "global using". It harkens to the auto-loading issues I've had with Rails. "Where was this defined? I dunno! It probably works here, though!!1" I generally don't like a random file impacting several other files. Extension methods are ... tolerated and ... "fine" but I still feel unpleasant using them. File-Scoped namespaces seem like someone's really, really tired of having nested folders a…
With respect to parameterless struct constructors: the reason why C# didn't have that historically is because there are many corner cases where those aren't invoked in CLR. Basically any place where you can't do "new" directly on the struct itself - e.g. when you create an array of structs, its elements do not have the constructor run for them. So C# designers originally decided that it would be less confusing overall if structs were always default-init, in all contexts - which means no parameterless constructors. I'm not sure what prompted the change of mind.