Can we have C# code directly without class?

[Thaina]

Normally C# can assume default namespace when compile. So I think, by assume default namespace , default class, default constructor. I think we could actually have cs file could be coded like python

I mean we could start write a function in a file and assume that it is a static function in default class of default namespace. Same go with specify namespace, everything can be assumed it is in default static class of that namespace and could be access directly within that namespace

// a.cs
using System;

/* after all using */

// namespace _default { static class _default { static double sqrt2; } }
double sqrt2 = Math.Sqrt(2);

// namespace _default { static class _default { static double Root(a,d) { } } }
double Root(double n,double d)
{
    return Math.Pow(n,1 / d);
}

namespace AA
{
    // static class _default { static double sqrt3 }
    double sqrt3 = Math.Sqrt(3);
    public class AA
    {
        double d2 = sqrt2; //_default._default.sqrt2
        double d3 = sqrt3; //AA._default.sqrt3
    }
}

namespace BB
{
   public class BB
    {
        double d2 = sqrt2;
        double d3 = sqrt3; // ERROR! BB don't contain sqrt3
        double d6 = AA.sqrt3; // Possible? Maybe we could use public and internal on those?
    }
}

I think by just assume default on everything it should already work if tweaking compiler and not need to require CLR support. Actually it more like syntactic sugar

[tenor]

C# Scripting/Interactive exists. Check it out https://github.com/dotnet/roslyn/wiki/C%23-Interactive-Walkthrough

[Thaina]

@tenor Yeah I know there are csx. I propose that, with some tweak, it should be valid in normal cs file and cs project

[tenor]

I recall there was a plan to be able to mix cs and csx files in the same project. I don't know if that's still in the roadmap.

[HaloFour]

The CLR has always allowed for global members. It was an explicit decision by the C# design teams a very long time ago to not permit declaring them. There's no benefit to using them over just defining static members in a class.

[dsaf]

@HaloFour

There's no benefit to using them over just defining static members in a class.

Depends on what you understand by benefit. Is marketing of language to new developers a benefit? Because the short is a runnable piece of code - the better. Though for me first step could be #595.

[alrz]

This will probably be abused for writing scattered spaghetti in non-trivial projects. static classes at least force you to make it coherent at a basic level.

[HaloFour]

@dsaf

Because the short is a runnable piece of code - the better.

No, the more coherent the running piece of code is, the better. Terseness quickly becomes a game of diminishing returns.

Is marketing of language to new developers a benefit?

C# is 5 on the TIOBE index. Java is 1. I don't think that the lack of global functions is doing either any harm.

[DavidArno]

@alrz,

That is my concern too. Initially I liked the idea, until I read down through @Thaina's example code and got to the namespace AA part. Then the penny dropped. This feature would be good for edge cases of apps/scripts needing say less ten lines of code, but could be abused to cram 1000's of lines into a single file, much of it without namespaces or classes.

The benefit it would bring to eg selling the shortness of C#'s de-facto "hello world" app over other languages would be far outweighed by the hideous mess that newbies could get themselves into, when not forced down the path of namespaces and classes to organise their code.

I'd still like to see #595 implemented though as I think the one less level of indentation brings many benefits and has the added advantage of discouraging multiple namespaces in one file and thus reducing the risk of spaghetti code.

[whoisj]

C# is 5 on the TIOBE index. Java is 1. I don't think that the lack of global functions is doing either any harm.

Yeah, well to comment on the 'value' of that list: assembly language is an 8 while TypeScript is 183. So I'm not sure that list means what you imply that it means. :wink:

[HaloFour]

@whoisj Indeed. I don't place a great deal of value in such lists. But if the argument is that C# is going to lose out on marketshare and mindshare due to egregious verbosity and boilerplate I think that the evidence shows otherwise.

For people who want to use C# as a terse scripting language C# interactive already allows you to skip the need for top-level classes, so in my opinion this itch is scratched.

[Thaina]

C# is 5 on the TIOBE index. Java is 1

Then why you don't use Java? Why still use C#?

Well, Java has no struct and does it do any harm to java position? Java has no true generic does it do any harm? Java lacks support on properties and lambda is it make java drop below C#?

So why C# need to have all those feature java don't support? When those feature came out MSDN blogger was always proudly present them that it will make people write code easier, more compact, more performance, or all of those

Does it harm Java in anyway from it first position? Then why they did it?

Well, I'm also don't think too far as C# will lose a lot of marketshare just by drop this feature. But "not a lot" does not mean it could be overlooked am I right?

[Thaina]

And marketshare of Java on TIOBE is just point out how many people need to use Java. It does not reflect that people actually hate verbosity and boilerplate or not

I'm also forced to use Java when I need to write android. And I hate it But I have no right to choose while I'm under command

I'm also the one in million who make java ranked on first TIOBE and now I try to have everything I want with language I love, because the language I hate make me want it

[HaloFour]

@Thaina

Then why you don't use Java? Why still use C#?

I do. I use many languages.

Java has no generic ... Java lacks support ... lambda

Java does have generics (albeit comparatively hobbled) and Java does have lambdas. Of course the reality is that there isn't one single set of features that makes a programming language useful or "better". There are things Java does that C# doesn't do and vice versa. At the end of the day both languages "get the job done".

None of this is an excuse to reverse an explicit decision made during the very early stages of the development of C#. C# isn't a scripting language and C# doesn't need to win the "shortest Hello World" competition. There isn't a single problem or scenario that global members would solve.

[Thaina]

@HaloFour Well I just edit to said "java has no true generic"

And java just support lambda recently. While C# was always support delegate and even lambda was so long before java. I could say java copy it because it actually work better than java interface

I belief verbosity is also one reason lambda is better than inline interface. Well sometimes I would like to have inline interface in C# too but it still just a very little times

And I have seen early stage of development in C# does not include generic. C# 1.x has no generic if you remember. And that also explicit decision to launch 1.0 without generic to have it in 2.0. I belief there are some other explicit decisions was broken from version 2-6, include return ref that was also explicit decision to not support in C#. There are 2 blogs about it around 2010 state that it possible in CLR but C# will not implement it

Also I don't see any problem if C# would be capable to write script. C# still able to write large and organize code beautifully in class and namespace. Just a void Main in one file become starting endpoint does not make whole project become a mess

On the contrary. To not write things that not really need is what should be called organize

[Thaina]

@DavidArno Well.. I think opposite that, if ones just write spaghetti code that cram everything in one file then, in namespace or class or not, it will be the same, newbie will just write code like that anyway

And spaghetti code with 2 indents just make it harder to read for us

Maybe I have write too many javascript so I have use it pattern of development too much But I think writing code to work first and refactor it when you feel it should be is not so bad

[HaloFour]

Not all language features are equal, either. Generics and lambdas both provided a great deal of positive impact across a wide array of projects. Even the JCP had to admit begrudgingly that lambda syntax (new as in 2 years old) is significantly better than tons of anonymous interface implementations buried in callbacks.

And yes, the team certainly may reverse earlier decisions, particularly when doing so provides benefit to the community. ref returns solves a problem that can't readily be handled in C# today. What benefit does global members provide aside encouraging awful and sloppy practices? None. There isn't a single problem that it solves.

Sure, newbies may still get it wrong, but the language shouldn't encourage them to jump into that pit.

Also I don't see any problem if C# would be capable to write script.

https://github.com/dotnet/roslyn/wiki/Interactive-Window

Hello World: WriteLine("Hello World!");

[Thaina]

Not all language features are equal, either. Generics and lambdas both provided a great deal of positive impact across a wide array of projects

@HaloFour

That's right I agree with that

But that means the argument about "explicit decision made during the very early stages" or rank in TIOBE is not a valid one What necessary is only the values of that feature. And I was understand you weight this feature very little. But I wish I would have a reasonable argument, not about legacy decision

Also I don't see a pit. Because, as I said, I don't think it difference for newbie to have spaghetti code with 2 indents or not Actually I think namespace block never stop newbie to write spaghetti code in one file. It only make us harder to refactor it

Also I don't think linq, not System.Linq but the linq syntax like select from, was solve any problem. This maybe subjective argument but I never see the usefulness of it. I have use a lot of array.Select but not even once that I write select a from array. So if it just to aid people who used to write SQL then I wish this could aid people who used to write script language

And actually this feature would be useful to write script language like unity. Not just one line interactive window

[HaloFour]

Also I don't see a pit. Because, as I said, I don't think it difference for newbie to have spaghetti code with 2 indents or not

No, but they see that a class is necessary. Namespaces have never been necessary.

Also I don't think linq, not System.Linq but the linq syntax like select from, was solve any problem.

You're free to have that opinion. I don't often resort to the query syntax either but I do think that clauses like let and join are easier than their method counterparts. Having that mental link to SQL was intentional.

And actually this feature would be useful to write script language like unity. Not just one line interactive window

Unity wouldn't benefit from this. They require all "scripts" to derive from MonoBehaviour, including those written in JavaScript where the class membership is implicit.

The legacy decision matters in that the team has already weighed in on this decision. New evidence may certainly sway that decision, but "being slightly less verbose" isn't new evidence. I'd bet someone already argued that point 17+ years ago. Assuming that anyone was actually willing to argue for such a thing.

[Thaina]

@HaloFour I don't mean unity itself but the way that game engine work toward this day mostly about attach script unity also have unityscript. which not derived from monobehaviour explicitly

I'd agree that someone already argued that point 17+ years ago. But as all the same things that was being argued 17+ years ago that C# don't need generic and return ref. So what now?

If you called my point on linq as opinion then yours on this feature too is your opinion. Everything is opinion from the start that what C# would look like at each version. So argument about 17+ years is invalid

At 17+ years ago there is no unity. At 17+ years ago C# was not an opensource on github. And most people using it today is newcomer, not only people in 17+ years ago

[HaloFour]

unity also have unityscript. which not derived from monobehaviour explicitly

All UnityScript members are wrapped automatically in a MonoBehaviour class. There are no global members in Unity, regardless of the language you use. C# global members would be of zero benefit to Unity because in Unity those members would still have to be declared within a class.

But as all the same things that was being argued 17+ years ago that C# don't need generic and return ref.

C# was always going to get generics. The CLR/language teams were always planning it. It just wasn't ready by the time 1.0 was to be released.

I severely doubt that ref returns were even on the radar 17 years ago. It's not like the design team had a list of every possible feature that could be requested and argued over all of them before intentionally omitting that feature from the language.

And most people using it today is newcomer, not only people in 17+ years ago

Apart from being absurd, if anything it's an argument against global members. They are a bad practice and newcomers should not be encouraged to use them.

on this feature too is your opinion.

Indeed it is and I wouldn't claim otherwise.

Any language feature needs to be objectively beneficial beyond the weight of implementation and permanent support. My opinion is that this proposal falls far below the bar.

[whoisj]

Personally, I'm of two minds about this.

There's general utility of having stand alone functions like _(string), die(string), usage(string), etc which are common in posix-y code; and there's the disaster of "functions, functions, everywhere!".

To be fair, with the advent of first class composition of types, non-class functions are starting to make more sense than they used to in C#.

[Thaina]

@HaloFour That's about unity implementation to it and I just point out one way game engine coding a script

I would not agree that they planning generic all along. It could be just and argument of minority that turn out to be actually crucial Because it is evidence that they proudly present C# 1.0 without generic. And that cause a lot of junk legacy in those gap between 1 and 2. We actually don't need whole System.Collections without generic and that was actually the worst design from the start that even today cannot get rid of it

And ref return, may not on 17+ years, but they actually support it in CLR at some point before C# 3. They just never expose it in C# so, again, I don't think they really planned to. But they must be some arguing and they just make a wrong decision. And that cause a serious damage to C# in game industry for decade

Only this 2 things is evidence that we should never trust decision made by early stage. Everything should be revised at some point

And now I think it's time for this one. It would turn out to be the same conclusion and that's fine by me but to bring decision of nearly 2 decades to weight is not a valid argument

Sure, the reason of old decision could be used as weight. But to blindly state that because it said so in early stage and it already have weight is like a religion, not a designing process

They are a bad practice

I think this is your actual valid opinion but we should argue about it because I don't agree with that. I never think why assume default class to function as a static function would encourage anyone to write spaghetti code. Because I never feel encouraged to write spaghetti code just because of I don't need to have class when I write C or js

Maybe I could also point to java that, with package and class and everything, there are always 1000 lines of code in one file of java anyway Bad coder will write bad code even in Java. Good coder will write good code even in C. Language not really could encourage them. So just make things easier to write is always better. And many language may give us tools to write better code. But in the end that still our choice to abuse it or use it for good sake

[HaloFour]

I would not agree that they planning generic all along. It could be just and argument of minority that turn out to be actually crucial

They were working on it as far back as 1998.

Everything should be revised at some point

Reviewed in the light of new evidence. I'm waiting on that new evidence.

Sure, the reason of old decision could be used as weight. But to blindly state that because it said so in early stage and it already have weight is like a religion, not an designing process

Sure it is. It established a precedent based on the arguments given at that time. If those arguments have not changed then why should the outcome?

We're simply not going to agree on this proposal.

I'd love to hear any feedback from any member of the team present that early on who could weigh in, good, bad or indifferent. It's historically interesting even if it has no bearing here.

[Thaina]

@HaloFour Because present day is not the same as 17+ years ago. You just talk about evidence but actually the current time is a whole evidence that need to be checked that what are difference from that day related to this things

Maybe you could dig the whole conversations at that time to state that there is nothing changed But then you need to declare it first, what all the reason on that day. So I could point out what difference in today If you cannot give me those arguments in the old day, then it was you who have no evidence. And we should just argue the reason about present day that only the values of this feature

[Thaina]

@HaloFour And as I said. I have already seen that blog before. But I not agree to call it "planned all along". Because as I said. It is just an idea that they, at least to the one who make decision in C# 1.0, don't think it necessary. And only the one who write blog is minority who lose in argument but turn out to be the right one

There must be argument that generic is not really necessary enough and just launch 1.0 without it. The launch of 1.0 itself is my evidence

And your blog already have evidence for me

being told by product team members that “generics is for academics only”

And to really quote him

The world is as it is today because we act when we have the chance to act, and because we invest in foundations that last the test of time. If you see a chance, take it.

That's what I always try to do. And you are just like product team member of that day

[HaloFour]

There must be argument that generic is not really necessary enough and just launch 1.0 without it. The launch of 1.0 itself is my evidence

That is a silly argument. C# 7.0 will launch without pattern matching. That doesn't mean that members of the C# team are arguing against pattern matching and claiming it to be a bad idea that shouldn't be implemented. Some things take time to implement. Generics were very complicated and took a very long time. How relevant would .NET have been if it wasn't released until late 2005?

Global members don't suffer from this same fate. The CLR has always supported it. The BCL has always supported it. At least one official Microsoft language supports it. There's just no reason for C# to support it.

You've yet to actually provide a use case where it would would make sense or be compelling. The language already goes to some length to make static members as easy to consume as globals.

[Thaina]

@HaloFour Now you are the one who don't stick with evidence here because evidently he said

being told by product team members that “generics is for academics only”

You crave for evidence from the start and now when evidence you present it yourself doesn't match with your argument you just not listen to it huh?

And to said "CLR has always supported it" are not make things better As I told you CLR was support return ref at around C# 2 - 3 and most people in game industry was beg for it. But even now they just implemented and not came out yet. That block our time of better performance for decade and waste our effort to do workaround the whole times. Code in game engine was verbose and ugly and those precious time wasted is already my fate

It not only this feature but every feature need to be think about instead of using the decision of people in 10+ years who have already made many critical decisions like generic and return ref gone horribly wrong

So your argument is invalid If you say that C# don't need this feature by some actual reason then I would like to hear But to worship the decision of early stage like this is not a valid argument

And my use case may not make sense in your eye But as you can see the evidence, the use case of generic in C# 1.0 was not in an eye of product team member at that times. They don't feel it compelling enough. They just seen it as academics feature

And then what happen after it got launched?

[HaloFour]

@Thaina

Yet they continued to work on it, for 7 years.

The validity of my argument isn't terribly relevant. This is your proposal. It's your burden to prove that it's worth implementing. Show the team how this is worth 200 points.

[Thaina]

@HaloFour I would not called it "continued to work on" because they never touch it until now. They just implement linq that I have seen no one ask for and proudly present it. I really appreciate their extension method but not linq

And yeah, talk about extension method. To pass extension method as value on struct is also another wrong decision. And now we can't fix it because it would break all the code they have already implemented. It now another junk legacy because they make wrong decision again

More and more evidence that decision of old times is wrong

And my proposal might seem a little benefit but it still has

BUT you are the one who try to disprove it. So your validity of argument is one factor to decide that my proposal has real benefit or not

If your argument is invalid it means benefit of my proposal is still the same as the start But if your argument is valid it means that my proposal has drawback to counter the benefit

However, if your argument is invalid why you still say it out then?

[HaloFour]

@Thaina

The beauty of inaction is that it can be remedied in the future. However, bad decisions are permanent.

And my proposal might seem a little benefit but it still has

Still waiting ...

This is your proposal. It's your burden to prove that it's worth implementing. Show the team how this is worth 200 points.

[Thaina]

@HaloFour In the future we all just die. Inaction is also one of bad decisions. And past is already permanent

[monoman]

Boo is a .NET language that has global functions and instances, being developed with Python as a guiding design. So it's Hello World is even terser, similar to GW Basic from 40 years ago:

print "Hello World"

Anyway with it's meta-programming features (print in Boo, for instance, is a macro like we've seen more recently in Rust), what it brings to the .NET languages ecosystem is more valuable than this point feature, that is making the noise level in this discussion hard to pass by.

F# also has global functions/instances which are rather conducive to good "functional" code, so there it's a natural fit, and conduce to best practices but C# is not F# ...

The important question is: the terser language will really help newbies come into the language and write good enough code?

And I think the point is moot, as my experience maintaining C# code from newbies that weren't properly mentored, over the last decades, is that even using the traditional syntax they tended to create enormous classes with lots of large methods with thousands of lines of duplicated code, copy-pasted, without change, between methods and between classes, because they didn't knew DRY and the ways of achieving it (inheritance, generics, function chaining,etc...), so probably they only would do the same copy-pasting without any class around it, what would make refactoring it onto a proper DRY design a little bit harder...

Anyway I vote NO for such a feature to prevent the certain headache for the fixers...

Rafael Teixeira O..:.)oooo

On Thu, Sep 29, 2016 at 3:24 PM, Thaina Yu notifications@github.com wrote:

@HaloFour https://github.com/HaloFour In the future we all just die. Inaction is also one of bad decisions. And past is already permanent

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dotnet/roslyn/issues/14143#issuecomment-250550144, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOfNAgRYtxwJXCoOcYOH4rvSCWk6KuFks5qvAJPgaJpZM4KIZAB .

[Thaina]

@monoman I like your detail explanation but I think I disagree that

even using the traditional syntax they tended to create enormous classes with lots of large methods with thousands of lines of duplicated code

I would say that, using the traditional syntax or not never really discourage them to do that kind of things. Only being mentored is effective

would make refactoring it onto a proper DRY design a little bit harder

I still don't know why refactor inside 2 indents and 2 blocks is easier than refactor from plain whole function

I think we all proper programmer always know there is no magic things with that additional 2 indents and 2 blocks. And as my experience refactor code like that. I think it is easier to refactor when I don't need to drag scrollbar to the right all the times

But in the newbie eye, I still remember I cannot distinguish that what code really do a work in static void Main example. What namespace do? what class do? All of that just add friction to newbie and we always said "you don't need to care what it do just put it there" But in the eye of newbie just naming things is all like magic. While I think it actually boring that I need to name a class and namespace that I don't really care about

Well... I think it is he same idea as tuple. You don't need to name what you really don't care. It just float X,Y,Z it could be point or vector or position. You don't really care where static void Main belongs to

[alrz]

In the future we all just die

💀

[mattwar]

This is still an open item for discussion for C# language design team. There are proponents that would like to merge the script syntax back into the primary language syntax. If we did that then it would likely end up looking like @Thaina proposes.

[Opiumtm]

For my opinion, global members are already sort-of emulated by using static language feature. You define static members within static class and then can import them as "global members".

So, I think, this proposal is already satisfied by existing language feature.

using static System.Console; 
using static System.Math;
class Program 
{ 
    static void Main() 
    { 
        WriteLine(Sqrt(3*3 + 4*4)); 
    } 
}

[Thaina]

@Opiumtm Your example present the thing I hate most and the reason of this proposal

Not about using static. I mean void Main()

Since Java that void Main() must be static in some class. There are no restriction to have multiple of it in separate class. And it cause ambiguous entry point

And using static cannot fix this problem

The point is not about only consuming API. It because some function or constant is too generic or too strict to have class in the first place

[redradist]

Normally C# can assume default namespace when compile. So I think, by assume default namespace , default class, default constructor. I think we could actually have cs file could be coded like python

I mean we could start write a function in a file and assume that it is a static function in default class of default namespace. Same go with specify namespace, everything can be assumed it is in default static class of that namespace and could be access directly within that namespace

// a.cs
using System;

/* after all using */

// namespace _default { static class _default { static double sqrt2; } }
double sqrt2 = Math.Sqrt(2);

// namespace _default { static class _default { static double Root(a,d) { } } }
double Root(double n,double d)
{
    return Math.Pow(n,1 / d);
}

namespace AA
{
    // static class _default { static double sqrt3 }
    double sqrt3 = Math.Sqrt(3);
    public class AA
    {
        double d2 = sqrt2; //_default._default.sqrt2
        double d3 = sqrt3; //AA._default.sqrt3
    }
}

namespace BB
{
   public class BB
    {
        double d2 = sqrt2;
        double d3 = sqrt3; // ERROR! BB don't contain sqrt3
        double d6 = AA.sqrt3; // Possible? Maybe we could use public and internal on those?
    }
}

I think by just assume default on everything it should already work if tweaking compiler and not need to require CLR support. Actually it more like syntactic sugar

Man, it is very very cool !! I have been dreaming about such language for a while which combine prototyping power of dinamic languages like Python with compiled languages like C#, C++ and etc.

I vote YES for this proposal !!

[redradist]

The important question is: the terser language will really help newbies come into the language and write good enough code?

And I think the point is moot, as my experience maintaining C# code from newbies that weren't properly mentored, over the last decades, is that even using the traditional syntax they tended to create enormous classes with lots of large methods with thousands of lines of duplicated code, copy-pasted, without change, between methods and between classes, because they didn't knew DRY and the ways of achieving it (inheritance, generics, function chaining,etc...), so probably they only would do the same copy-pasting without any class around it, what would make refactoring it onto a proper DRY design a little bit harder...

Anyway I vote NO for such a feature to prevent the certain headache for the fixers...

Rafael Teixeira O..:.)oooo

On Thu, Sep 29, 2016 at 3:24 PM, Thaina Yu notifications@github.com wrote:

@HaloFour https://github.com/HaloFour In the future we all just die. Inaction is also one of bad decisions. And past is already permanent — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub #14143 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAOfNAgRYtxwJXCoOcYOH4rvSCWk6KuFks5qvAJPgaJpZM4KIZAB .

You cannot stop programmers to write bad code !! Almost all features of programming languages without understanding what you are doing can be written in bad taste !! But if feature allow to write a good code and it feet into language pretty good, why not to add it ? I vote YES !!

[HaloFour]

@redradist

You cannot stop programmers to write bad code !!

The language shouldn't encourage it either.

But if feature allow to write a good code and it feet into language pretty good, why not to add it ?

The reason to not add a feature is that any feature is incredibly expensive to add. The feature must demonstrate value above and beyond the costs in designing, implementing, testing and (permanently) supporting it.

[redradist]

@HaloFour

@redradist

You cannot stop programmers to write bad code !!

The language shouldn't encourage it either.

But if feature allow to write a good code and it feet into language pretty good, why not to add it ?

The reason to not add a feature is that any feature is incredibly expensive to add. The feature must demonstrate value above and beyond the costs in designing, implementing, testing and (permanently) supporting it.

The advantages of this feature is incredible !! Pros: 1) It will be easier for new developer to learn language, while playing with it. It is significant power !! 2) It will allow rapidly prototype !! 3) It will allow to share code not only by assembly, but also on code source. You will just need to copy-past example in file and run it ... Due to this learning the new API, Frameworks become easier 4) It will improve maintenance of some pieces of code, because simple code - also more maintainable code

Cons: 1) Someone should relearn

[monoman]

Denis you didn't understand Halofour !

When he said: 'costs in designing, implementing, testing and (permanently) supporting it.' he meant in terms of the Roslyn project.

1. Your design has many holes, like adopting a fixed name for the default class that may collide with other classes in existing code.
2. Implementing it, specially with support to mix namespaces (thus creating multiple default classes) and doing the the name resolution for the 'free' methods is non-trivial, even if we try to reuse "using static" machinery.
3. Testing it may bring too many corner-cases of ambiguity to add to the test suite
4. Further evolution of the language may be negatively impacted by maintaining compatibility with such new 'feature'

That someone should learn this 'simpler' syntax is not a real issue.

But to be sure, part of what you want is available in the "C# Interactive" shell, that now is embedded in Visual Studio. I just did this there:

Microsoft (R) Roslyn C# Compiler version 2.10.0.0 Loading context from 'CSharpInteractive.rsp'. Type "#help" for more information.

using static System.Console; WriteLine("Hello World"); Hello World

And you can save it as ".csx" script and run in the command line...

Rafael Teixeira O..:.)oooo

On Fri, Jan 18, 2019 at 3:12 PM Denis notifications@github.com wrote:

@redradist https://github.com/redradist

You cannot stop programmers to write bad code !!

The language shouldn't encourage it either.

But if feature allow to write a good code and it feet into language pretty good, why not to add it ?

The reason to not add a feature is that any feature is incredibly expensive to add. The feature must demonstrate value above and beyond the costs in designing, implementing, testing and (permanently) supporting it.

The cost of this feature is incredible !! Pros:

1. It will be easier for new developer to learn language, while playing with it. It is significant power !!
2. It will allow rapidly prototype !!
3. It will allow to share code not only by assembly, but also on code source. You will just need to copy-past example in file and run it ... Due to this learning the new API, Frameworks become easier
4. It will improve maintenance of some pieces of code, because simple code - also more maintainable code Cons:
5. Someone should relearn

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/roslyn/issues/14143#issuecomment-455619828, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOfNKF2NCuk3VQhJxe4ipGi450AR5Vmks5vEgCAgaJpZM4KIZAB .

[redradist]

@monoman

Denis you didn't understand Halofour ! When he said: 'costs in designing, implementing, testing and (permanently) supporting it.' he meant in terms of the Roslyn project. 1. Your design has many holes, like adopting a fixed name for the default class that may collide with other classes in existing code. 2. Implementing it, specially with support to mix namespaces (thus creating multiple default classes) and doing the the name resolution for the 'free' methods is non-trivial, even if we try to reuse "using static" machinery. 3. Testing it may bring too many corner-cases of ambiguity to add to the test suite 4. Further evolution of the language may be negatively impacted by maintaining compatibility with such new 'feature' That someone should learn this 'simpler' syntax is not a real issue. But to be sure, part of what you want is available in the "C# Interactive" shell, that now is embedded in Visual Studio. I just did this there: Microsoft (R) Roslyn C# Compiler version 2.10.0.0 Loading context from 'CSharpInteractive.rsp'. Type "#help" for more information. using static System.Console; WriteLine("Hello World"); Hello World And you can save it as ".csx" script and run in the command line... Rafael Teixeira O..:.)oooo … On Fri, Jan 18, 2019 at 3:12 PM Denis @.**> wrote: @redradist https://github.com/redradist You cannot stop programmers to write bad code !! The language shouldn't encourage it either. But if feature allow to write a good code and it feet into language pretty good, why not to add it ? The reason to not add a feature is that any feature is incredibly* expensive to add. The feature must demonstrate value above and beyond the costs in designing, implementing, testing and (permanently) supporting it. The cost of this feature is incredible !! Pros: 1. It will be easier for new developer to learn language, while playing with it. It is significant power !! 2. It will allow rapidly prototype !! 3. It will allow to share code not only by assembly, but also on code source. You will just need to copy-past example in file and run it ... Due to this learning the new API, Frameworks become easier 4. It will improve maintenance of some pieces of code, because simple code - also more maintainable code Cons: 5. Someone should relearn — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14143 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOfNKF2NCuk3VQhJxe4ipGi450AR5Vmks5vEgCAgaJpZM4KIZAB .

You are taking about costs in designing ? But C# Interactive Team has already paid this cost and continue paying this cost. Seems like you do not count a cost of maintenance two separate projects ?! It is inconsistent and make a lot of confusion (

[monoman]

Denis, C# Interactive didn't change the language, they have a front-end that gets each line and wraps it in the normal C# syntax, compiles and executes that line saving the state to preserve variables for the next compilation and execution in the same interactive session, it is very different from the compiler itself. Seems you didn't look into Roslyn code, including C# interactive, to see how things are really done...

Rafael Teixeira O..:.)oooo

On Fri, Jan 18, 2019 at 4:07 PM Denis notifications@github.com wrote:

@monoman https://github.com/monoman

Denis you didn't understand Halofour ! When he said: 'costs in designing, implementing, testing and (permanently) supporting it.' he meant in terms of the Roslyn project. 1. Your design has many holes, like adopting a fixed name for the default class that may collide with other classes in existing code. 2. Implementing it, specially with support to mix namespaces (thus creating multiple default classes) and doing the the name resolution for the 'free' methods is non-trivial, even if we try to reuse "using static" machinery. 3. Testing it may bring too many corner-cases of ambiguity to add to the test suite 4. Further evolution of the language may be negatively impacted by maintaining compatibility with such new 'feature' That someone should learn this 'simpler' syntax is not a real issue. But to be sure, part of what you want is available in the "C# Interactive" shell, that now is embedded in Visual Studio. I just did this there: Microsoft (R) Roslyn C# Compiler version 2.10.0.0 Loading context from 'CSharpInteractive.rsp'. Type "#help" for more information. using static System.Console; WriteLine("Hello World"); Hello World And you can save it as ".csx" script and run in the command line... Rafael Teixeira O..:.)oooo … <#m2940131752438290781> On Fri, Jan 18, 2019 at 3:12 PM Denis @.**> wrote: @redradist https://github.com/redradist https://github.com/redradist You cannot stop programmers to write bad code !! The language shouldn't encourage it either. But if feature allow to write a good code and it feet into language pretty good, why not to add it ? The reason to not add a feature is that any feature is incredibly* expensive to add. The feature must demonstrate value above and beyond the costs in designing, implementing, testing and (permanently) supporting it. The cost of this feature is incredible !! Pros: 1. It will be easier for new developer to learn language, while playing with it. It is significant power !! 2. It will allow rapidly prototype !! 3. It will allow to share code not only by assembly, but also on code source. You will just need to copy-past example in file and run it ... Due to this learning the new API, Frameworks become easier 4. It will improve maintenance of some pieces of code, because simple code - also more maintainable code Cons: 5. Someone should relearn — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14143 (comment) https://github.com/dotnet/roslyn/issues/14143#issuecomment-455619828>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOfNKF2NCuk3VQhJxe4ipGi450AR5Vmks5vEgCAgaJpZM4KIZAB .

You are taking about costs in designing ? But C# Interactive Team has already pay this cost and continue paying this cost. Seems like you do not count a cost of maintenance two separate projects ?! It is inconsistent and make a lot of confusion (

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/roslyn/issues/14143#issuecomment-455636269, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOfNKsXNFr1R3pFLK6mDKx9GvUpE5Adks5vEg1TgaJpZM4KIZAB .

[redradist]

@monoman

Denis, C# Interactive didn't change the language, they have a front-end that gets each line and wraps it in the normal C# syntax, compiles and executes that line saving the state to preserve variables for the next compilation and execution in the same interactive session, it is very different from the compiler itself. Seems you didn't look into Roslyn code, including C# interactive, to see how things are really done... Rafael Teixeira O..:.)oooo … On Fri, Jan 18, 2019 at 4:07 PM Denis @.> wrote: @monoman https://github.com/monoman Denis you didn't understand Halofour ! When he said: 'costs in designing, implementing, testing and (permanently) supporting it.' he meant in terms of the Roslyn project. 1. Your design has many holes, like adopting a fixed name for the default class that may collide with other classes in existing code. 2. Implementing it, specially with support to mix namespaces (thus creating multiple default classes) and doing the the name resolution for the 'free' methods is non-trivial, even if we try to reuse "using static" machinery. 3. Testing it may bring too many corner-cases of ambiguity to add to the test suite 4. Further evolution of the language may be negatively impacted by maintaining compatibility with such new 'feature' That someone should learn this 'simpler' syntax is not a real issue. But to be sure, part of what you want is available in the "C# Interactive" shell, that now is embedded in Visual Studio. I just did this there: Microsoft (R) Roslyn C# Compiler version 2.10.0.0 Loading context from 'CSharpInteractive.rsp'. Type "#help" for more information. using static System.Console; WriteLine("Hello World"); Hello World And you can save it as ".csx" script and run in the command line... Rafael Teixeira O..:.)oooo … <#m2940131752438290781> On Fri, Jan 18, 2019 at 3:12 PM Denis @.> wrote: @redradist https://github.com/redradist https://github.com/redradist You cannot stop programmers to write bad code !! The language shouldn't encourage it either. But if feature allow to write a good code and it feet into language pretty good, why not to add it ? The reason to not add a feature is that any feature is incredibly expensive to add. The feature must demonstrate value above and beyond the costs in designing, implementing, testing and (permanently) supporting it. The cost of this feature is incredible !! Pros: 1. It will be easier for new developer to learn language, while playing with it. It is significant power !! 2. It will allow rapidly prototype !! 3. It will allow to share code not only by assembly, but also on code source. You will just need to copy-past example in file and run it ... Due to this learning the new API, Frameworks become easier 4. It will improve maintenance of some pieces of code, because simple code - also more maintainable code Cons: 5. Someone should relearn — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14143 (comment) <#14143 (comment)>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOfNKF2NCuk3VQhJxe4ipGi450AR5Vmks5vEgCAgaJpZM4KIZAB . You are taking about costs in designing ? But C# Interactive Team has already pay this cost and continue paying this cost. Seems like you do not count a cost of maintenance two separate projects ?! It is inconsistent and make a lot of confusion ( — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14143 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOfNKsXNFr1R3pFLK6mDKx9GvUpE5Adks5vEg1TgaJpZM4KIZAB .

Anyway, we should not count the cost if it is needed by Community. If it is hard to do at one big step we could decompose: 1) Add top-level functions (free functions) 2) Add top-level variable 3) Add top-level statements (free statements)

My point that it is solvable !! We just need as community to decide that these features is needed for us based on experiences from other programming languages

[HaloFour]

Anyway, we should not count the cost if it is needed by Community.

The cost is real and must always be considered.

We just need as community to decide that these features is needed for us based on experiences from other programming languages

The C# language isn't a democracy, changes are only made if members of the language team are willing to "champion" the proposal and take it up at design meetings, which is still far from a guarantee that it will be accepted and adopted into the language.

The only chance I see of this happening is if the team feels that parity with C# Interactive is worth it. But given C# Interactive adoption appears to have stalled and short of a comment over two years ago there seems to be no movement from language design members my take is that it's not likely that this will ever happen.

Beyond C# Interactive parity, I see zero reason to add this to the language. It would be a lot if work and it solves zero problems. At most it makes code more terse by a matter of a couple of dozen characters.

[CyrusNajmabadi]

Closing this out. We're doing all language design now at dotnet/csharplang. If you're still interested in this idea let us know and we can migrate this over to a discussion in that repo. Thanks!

[redradist]

@CyrusNajmabadi

Closing this out. We're doing all language design now at dotnet/csharplang. If you're still interested in this idea let us know and we can migrate this over to a discussion in that repo. Thanks!

+1