Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

First C# 7 Design Meeting Notes

github.com

Post reply on HN
Print view View original

71–80 of 82 posts

Re: First C# 7 Design Meeting Notes

#71

Post by azth »

noblethrasher wrote: post #67
azth wrote: post #66

Earlier quoted context omitted.

> but I do admire Java for making it significantly more painful to write mutable rather than immutable classes; Out of curiosity, how does it do that? As far as I know, everything in Java is mutable by default.

You have to go through the extra ceremony of writing a setter.

The same applies to C# though, correct? Plus, I was thinking more of the lines of something like:

    class Foo {
      private int x = 0;

      public void bar() {
        this.x += 1; // Whoops!
      }
    }

    Foo x = new Foo();
    x.bar(); // Mutating call.
Which Java does not prevent.

Re: First C# 7 Design Meeting Notes

#72

Post by MichaelGG »

noblethrasher wrote: post #59
mhomde wrote: post #26

I've been trying to think of something that drastically change how I coded. Bugs and productivity really are the two major dragons to slay. I'm just spitballing here but something I'd really like to see stuff like code contracts and unit testing, but more integrated with the language, less verbose and requiring less to setup. Being able to let the "meat" of a method be separated from all the error-checking, post, pre…

We've had a robust way of doing code contracts since C# 2.0. If you instruct the compiler to treat all warnings as errors (so that variables must be defintitely assigned), then the following code gives you what you want: public PositiveInt SomeMethod(GreaterThanFive a, NonNegative b) { //do stuff; } public struct GreaterThanFive { readonly int n; public GreaterThanFive (int n) { if(n We can even have nice diagnostic…

Very clever. It may be robust, but is ridiculously verbose and feels sorta obfuscatory. Also pays a runtime penalty unless they've improved the CLR codegen.

It also might not be super amenable to static analysis.

Re: First C# 7 Design Meeting Notes

#73

Post by noblethrasher »

MichaelGG wrote: post #72
noblethrasher wrote: post #59

Earlier quoted context omitted.

We've had a robust way of doing code contracts since C# 2.0. If you instruct the compiler to treat all warnings as errors (so that variables must be defintitely assigned), then the following code gives you what you want: public PositiveInt SomeMethod(GreaterThanFive a, NonNegative b) { //do stuff; } public struct GreaterThanFive { readonly int n; public GreaterThanFive (int n) { if(n We can even have nice diagnostic…

Very clever. It may be robust, but is ridiculously verbose and feels sorta obfuscatory. Also pays a runtime penalty unless they've improved the CLR codegen. It also might not be super amenable to static analysis.

But, structs pay a very small runtime penalty, if at all, right?

The verbosity will be mostly ameliorated with primary constructor. I propose going further by allowing programmers to annotate constructors so that they can be used as user-defined conversion operators.

Thus, the aforementioned code could become something like:

	 public struct GreaterThanFive implicit (int n)
	 {
	 	readonly int n = n;

	 	if(n

Re: First C# 7 Design Meeting Notes

#74

Post by noblethrasher »

azth wrote: post #71
noblethrasher wrote: post #67

Earlier quoted context omitted.

You have to go through the extra ceremony of writing a setter.

The same applies to C# though, correct? Plus, I was thinking more of the lines of something like: class Foo { private int x = 0; public void bar() { this.x += 1; // Whoops! } } Foo x = new Foo(); x.bar(); // Mutating call. Which Java does not prevent.

Yes, the same applies to my beloved C#, but that language was much less hostile to immutability. Indeed, the prettier mutator syntax was even positioned as a feature once upon a time.

To be clear, I'm the guy that insists on defining classes as either abstract or sealed, and almost always marks fields as readonly. But, I'm okay with the kind bounded mutability that you mentioned; clients of a `Foo` instance have to treat it as immutable.

Here is how I do OOP:

* I make classes to hide state, and hidden state is the same as being stateless.

* As I learn more about the problem, I start subdividing classes into smaller classes (not necessarily via inheritance).

* So, as my understanding of the problem increases, the number of class division increases, and by the pigeonhole principle, the amount of state approaches zero.

Re: First C# 7 Design Meeting Notes

#75

Post by steveklabnik »

pjmlp wrote: post #48
MichaelGG wrote: post #42

Earlier quoted context omitted.

F# doesn't (or didn't) use tailcall in CLR in general, because it was too slow. It only does so as a last resort. Or did that all change? Same with stuff like tuples. We get tons of heap allocations because the CLR did poorly with structs. F# had to even go back on their design because of this, and match the BCL tuple type. MS doesn't need to sell the typical enterprise dev. They just need to not sour-coat things and…

> Let me know when Microsoft starts shipping Rust-level features, so we can deal with memory safely and reduce bugs without losing perf. Is Rust 1.0 out yet? They are on Microsoft research. While the world still isn't ready for the likes of Singularity and IronClad, Spec# and Dafny, at least part of the technology has landed on Windows Phone 8 and .NET Native compilers.

Rust 1.0 is currently slated for 8-14 weeks away: http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

Re: First C# 7 Design Meeting Notes

#76

Post by MichaelGG »

noblethrasher wrote: post #73
MichaelGG wrote: post #72

Earlier quoted context omitted.

Very clever. It may be robust, but is ridiculously verbose and feels sorta obfuscatory. Also pays a runtime penalty unless they've improved the CLR codegen. It also might not be super amenable to static analysis.

But, structs pay a very small runtime penalty, if at all, right? The verbosity will be mostly ameliorated with primary constructor. I propose going further by allowing programmers to annotate constructors so that they can be used as user-defined conversion operators. Thus, the aforementioned code could become something like: public struct GreaterThanFive implicit (int n) { readonly int n = n; if(n

Traditionally, structs paid a large codegen penalty, as a lot of optimizations and stuff were turned off. It also seemed like the codegen wasn't super smart about passing them around. Maybe that's all changed.

I meant the verbosity of having to create a custom type for each kind of restriction, versus some inline "int n [n > 5]" notation.

Re: First C# 7 Design Meeting Notes

#77

Post by MichaelGG »

kirse wrote: post #55
MichaelGG wrote: post #44

Earlier quoted context omitted.

It's a self fulfilling prophecy. F# is weak at designing full stack apps because it lacks tooling because it is weak at designing full stack apps. Even now, doing MVC websites is far more difficult out of the box if I code F#. MS still lacks JS backends, so we need third party compilers for that model... Maybe because they don't want to upset or look less than 1000% behind typescript. I will say though otherwise I'm…

F# is weak at designing full stack apps because it lacks tooling because it is weak at designing full stack apps. This is just something that takes time and commitment from the community. It's only ~7 years old at this point, and if everyone just sits back and whines about the lack of tooling without, y'know, building & releasing something themselves, it'll be an ongoing problem. It's the "take take take" mentality -…

You're right, I am just whining.

But more to the point, I am pointing out that Microsoft is not treating F# like C#, not giving it the same resources. No one says C# users are just whining when they wanted, say, edit and continue.

Has any community, ever, stepped up and offered an experience as good as Visual Studio's? I mean, that's sort of a major reason Microsoft makes and sells that product.

Yes WebSharper is pretty awesome. But I still don't see why we shouldn't criticize MS for not doing something like that directly. After all, MS got flack over ASP.NET Web Forms then went and put resources into MVC.

Re: First C# 7 Design Meeting Notes

#78

Post by MichaelGG »

olavk wrote: post #53
andyjohnson0 wrote: post #51

Earlier quoted context omitted.

What are the advantages that language-level tuples would have over the existing System.Tuple class?

The ability to write (2, "hello") instead of Tuple.Create(2, "Hello"). But more importantly, syntax for deconstructing tuples will make tuples convenient for returning multiple values from a method. Eg.: (var x, var y) = getPoint(); as shown in the aticle.

Also, the type is simpler to represent. Instead of Tuple you just have something like (Int, String).

Re: First C# 7 Design Meeting Notes

#79

Post by noblethrasher »

MichaelGG wrote: post #76
noblethrasher wrote: post #73

Earlier quoted context omitted.

But, structs pay a very small runtime penalty, if at all, right? The verbosity will be mostly ameliorated with primary constructor. I propose going further by allowing programmers to annotate constructors so that they can be used as user-defined conversion operators. Thus, the aforementioned code could become something like: public struct GreaterThanFive implicit (int n) { readonly int n = n; if(n

Traditionally, structs paid a large codegen penalty, as a lot of optimizations and stuff were turned off. It also seemed like the codegen wasn't super smart about passing them around. Maybe that's all changed. I meant the verbosity of having to create a custom type for each kind of restriction, versus some inline "int n [n > 5]" notation.

In addition to the benefit of brevity, something like your proposal also has the virtue of being compatible with the `checked/unchecked` keywords.

Re: First C# 7 Design Meeting Notes

#80

Post by pjmlp »

steveklabnik wrote: post #75
pjmlp wrote: post #48

Earlier quoted context omitted.

> Let me know when Microsoft starts shipping Rust-level features, so we can deal with memory safely and reduce bugs without losing perf. Is Rust 1.0 out yet? They are on Microsoft research. While the world still isn't ready for the likes of Singularity and IronClad, Spec# and Dafny, at least part of the technology has landed on Windows Phone 8 and .NET Native compilers.

Rust 1.0 is currently slated for 8-14 weeks away: http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

I know, and comparing its current state with what F# offers today doesn't make sense, not today.

In a few years time when Rust has the same eco-system has F# offers today to Windows devs, then we can compare the current state of the languages.

Post reply on HN