Maybe it's me, because I'm a perfectionist, but some of these features feel not elegant enough. Still, better than without but if you also program in like F#, Haskell or Rust... you can't not feel that they could have spent more time and do a better job... like having to check the Deconstruct signature to know how to deconstruct instead of making it discoverable by the compiler and thus the programmer through IntelliSense.
When I first heard of default interface implementations I agreed with you, but after using it for a while I've partially converted. Don't do it too often, but there are definitively scenarios where they're very useful. static members however are very nice, and should've existed years ago
The biggest reason for default interface implementations is to make it easier to interoperate with APIs that have similar features, like Android and iOS frameworks. It is not necessarily something you would use in your everyday C# application.
A longer comment I tried to make explaining when it absolutely makes sense sadly gets auto-nuked, so here's a short version: Look at something like an "alter" method on any key-value storage that can be default-implemented by Get and Insert/Put individually, but may be more efficiently implemented by any particular container itself. If you make it a part of the interface you increase the parametricity of your code that could use this "alter" method. The example he showed in the presentation, with the default-constructed return value, is pretty asinine and does not present the feature correctly.
Thanks for the upload! Didn't know that Deconstruct was a feature of C# 7 actually!
I refuse to believe that I got Rickroll in a .NET conference. Every day, we stray further from god.
This is a talk about C# 8, 9, and 10, several months after the release of C# 11...?
This talk was done before the release of C# 11, its just now being uploaded to UA-cam.
@@allesarfint ah, makes sense. sorry
Maybe it's me, because I'm a perfectionist, but some of these features feel not elegant enough. Still, better than without but if you also program in like F#, Haskell or Rust... you can't not feel that they could have spent more time and do a better job... like having to check the Deconstruct signature to know how to deconstruct instead of making it discoverable by the compiler and thus the programmer through IntelliSense.
Don’t expand interfaces - The bigger the interface the smaller the abstraction.
When I first heard of default interface implementations I agreed with you, but after using it for a while I've partially converted. Don't do it too often, but there are definitively scenarios where they're very useful.
static members however are very nice, and should've existed years ago
The biggest reason for default interface implementations is to make it easier to interoperate with APIs that have similar features, like Android and iOS frameworks.
It is not necessarily something you would use in your everyday C# application.
A longer comment I tried to make explaining when it absolutely makes sense sadly gets auto-nuked, so here's a short version:
Look at something like an "alter" method on any key-value storage that can be default-implemented by Get and Insert/Put individually, but may be more efficiently implemented by any particular container itself. If you make it a part of the interface you increase the parametricity of your code that could use this "alter" method. The example he showed in the presentation, with the default-constructed return value, is pretty asinine and does not present the feature correctly.