Discussion :

[tomlev]

Bonjour,

Cette discussion est destinée à recevoir vos commentaires concernant l'article Les nouveautés de C# 6.

Lors de la conférence BUILD 2014, Microsoft a fait plusieurs annonces importantes ; la plus marquante, de mon point de vue de développeur, est que le projet Roslyn est maintenant open source ! Pour rappel, il s'agit du nouveau compilateur pour C# et VB.NET. Du coup, bien que le projet ne soit pas encore terminé, la liste des nouveautés des langages est déjà disponible, et on peut même commencer à jouer avec certaines d'entre elles. Cet article se propose de faire un petit tour d'horizon des nouveautés prévues pour C# 6.

[worm83]

Bonjour,

Merci pour cet article.

J'aime bien dans l'ensemble les facilités apportées par cette nouvelle version.
Le seul truc qui me fait "tické" est cela car je le trouve "brouillon". Le reste est très intéressante.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
  class Point(private readonly int x, private readonly int y) 
    { 
 
        public int X { get { return x; } } 
 
        public int Y { get { return y; } } 
 
    }

[Jabbal'H]

Bonjour,

Merci pour cet article.

J'aime bien dans l'ensemble les facilités apportées par cette nouvelle version.
Le seul truc qui me fait "tické" est cela car je le trouve "brouillon". Le reste est très intéressante.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
  class Point(private readonly int x, private readonly int y) 
    { 
 
        public int X { get { return x; } } 
 
        public int Y { get { return y; } } 
 
    }

Idem ca pique un peu.

Une autre chose, mais c'est peut être moi, c'est quoi l’intérêt de çà ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
public int Answer { get; } = 42;

C'est presque une constante, ou bien cela provient du fait de pouvoir faire çà

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
public class Point(int x, int y) 
{ 
    public int X { get; } = x; 
    public int Y { get; } = y; 
}

Pour le reste, de belles évolutions ! Vivement dans 5 ans qu'on puisse l'utiliser en entreprise :d

[worm83]

Une autre chose, mais c'est peut être moi, c'est quoi l’intérêt de çà ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
public int Answer { get; } = 42;

Je trouve cela pratique ça t'évite de faire cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
 
int _Answer = 42;
 
public int Answer{get{return _Answer;}

Ou d'écrire le constructeur sans argument pour initialiser Answer.
Après sur une classe conséquente ça doit être un peu bordélique (remarque : pas plus que d'avoir pleins de membre privés initialisés à la déclaration ).

[tomlev]

Le seul truc qui me fait "tické" est cela car je le trouve "brouillon". Le reste est très intéressante.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
  class Point(private readonly int x, private readonly int y) 
    { 
 
        public int X { get { return x; } } 
 
        public int Y { get { return y; } } 
 
    }

Dans ce cas précis ça n'a effectivement pas beaucoup d'intérêt, il serait plus simple de faire ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
  class Point(int x, int y) 
    { 
 
        public int X { get; } =x;
 
        public int Y { get; } = y;
 
    }

Mais il peut y avoir des cas où c'est utile : par exemple si tu ne veux pas exposer le champ via une propriété, ça t'évite de faire un constructeur où tu dois explicitement initialiser le champ.

Une autre chose, mais c'est peut être moi, c'est quoi l’intérêt de çà ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
public int Answer { get; } = 42;

C'est presque une constante

C'est plutôt comme un champ public readonly en fait ; au niveau de la compilation, ce sera traité comme une propriété et non comme une constante. Surtout, ça permet de modifier l'implémentation plus tard si nécessaire sans changer l'interface publique de la classe : rien ne t'empêche à l'avenir de modifier la propriété pour renvoyer autre chose, et le code qui en dépend ne sera pas impacté.

ou bien cela provient du fait de pouvoir faire çà

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
public class Point(int x, int y) 
{ 
    public int X { get; } = x; 
    public int Y { get; } = y; 
}

Oui, c'est la possibilité d'initialiser une propriété auto et de pouvoir faire une propriété auto en lecture seule.

Pour le reste, de belles évolutions ! Vivement dans 5 ans qu'on puisse l'utiliser en entreprise :d

Pas forcément ; comme je le disais dans la conclusion, même si tu cibles une version plus ancienne de .NET, la plupart de ces fonctionnalités sont quand même utilisables. J'ai testé en compilant pour .NET 2, tout marche sans problème (à part bien sûr ce qui est lié à async/await)

[Jabbal'H]

Ah oui effectivement, j'avais la tête ailleurs :d

[Arnard]

De petits ajouts très sympathiques, avec un coup de cœur pour :
- Expressions de déclaration (on va pouvoir spammer les TryParse avec moins de ligne OUAAAIIIISSSSS)
- Catch conditionnels
- Initialiseurs dans l'initialiseur (bon, p'tete mois répandu à l'usage, mais quand même)

Nice.

Y'a une idée de quand ils veulent release tout ça ? Courant 2014 ? 2015 ?

PS : merci pour ces infos

[DonQuiche]

Avant toute chose, merci, d'autant que l'article examine en détail ces nouvelles fonctionnalités, de façon plus claire que ce que j'avais vu jusque là.



Sur le fond je suis assez chagriné : des petites choses sympas mais sans plus. Pas de mixins ou de nouvelles contraintes génériques ou de corps de méthodes dans les interfaces, des ajouts qui me semblaient pourtant plus que nécessaires. Et certaines syntaxes me semble un peu malheureuses (les "membres dont le corps est une expression" dépareillent trop des autres membres par exemple) ou ont des limitations inutiles (proprios en lecture seule initialisables uniquement depuis le seul constructeur primaire).


Gros regret notamment : les constructeurs primaires auraient pu être un vrai bonus pour la concision du code lorsqu'il s'agit de déclarer des classes immuables ou POCO. On sent qu'ils ont fortement lorgné sur la prog fonctionnelle. Malheureusement il manque une mise en œuvre automatisée de comparaisons structurelles (voire de relations d'ordonnancement) et de hash codes, indispensables pour adapter les motifs de la prog fonctionelle. Du coup on économisera seulement trois lignes au lieu d'en économiser trente ou quarante.


A part ça j'apprécierai quand même les constructeurs primaires, les déclarations en ligne pour "out", les private protected et le fameux opérateur .?

[tomlev]

- Expressions de déclaration (on va pouvoir spammer les TryParse avec moins de ligne OUAAAIIIISSSSS)

En fait pour le TryParse, je préfèrerais de loin que ça renvoie un nullable :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int? x = int.TryParse(text);
// ou encore
int y = int.TryParse(text) ?? 0;

Y'a une idée de quand ils veulent release tout ça ? Courant 2014 ? 2015 ?

Aucune idée, mais vu qu'il y a encore un petit paquet de fonctionnalités à implémenter, je dirais pas avant 6 mois (en étant optimiste) ou un an... en attendant, rien n'empêche de jouer avec les fonctionnalités déjà prêtes

Sur le fond je suis assez chagriné : des petites choses sympas mais sans plus. Pas de mixins ou de nouvelles contraintes génériques ou de corps de méthodes dans les interfaces, des ajouts qui me semblaient pourtant plus que nécessaires.

La liste des fonctionnalités "plus que nécessaires" est malheureusement assez longue , et ils ne peuvent pas tout faire à la fois...
Le gros chantier de cette version est le compilateur Roslyn, tout le reste est du bonus. Mais tel que je vois les choses, ça va rendre les futures évolutions plus faciles à implémenter, donc on verra peut-être arriver les nouvelles fonctionnalités plus rapidement... Perso le truc que j'aimerais bien avoir c'est le "tuple unpacking" des langages fonctionnels, pour pouvoir faire des choses comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var (x, y) = MethodQuiRenvoieUnTuple();

Pour les "corps de méthodes dans les interfaces", tu veux dire quoi au juste ? tu penses aux defender methods de Java 8 ?

Et certaines syntaxes me semble un peu malheureuses (les "membres dont le corps est une expression" dépareillent trop des autres membres par exemple)

Oui, c'est un peu bizarre, mais on s'y fera je pense... la concision que ça apporte justifie bien un petit effort d'adaptation à mon avis.

ou ont des limitations inutiles (proprios en lecture seule initialisables uniquement depuis le seul constructeur primaire).

Comment ça ? Tu peux les initialiser inline, avec ou sans constructeur primaire... Tu voudrais pouvoir les initialiser depuis un constructeur normal ?

Gros regret notamment : les constructeurs primaires auraient pu être un vrai bonus pour la concision du code lorsqu'il s'agit de déclarer des classes immuables ou POCO. On sent qu'ils ont fortement lorgné sur la prog fonctionnelle. Malheureusement il manque une mise en œuvre automatisée de comparaisons structurelles (voire de relations d'ordonnancement) et de hash codes, indispensables pour adapter les motifs de la prog fonctionelle. Du coup on économisera seulement trois lignes au lieu d'en économiser trente ou quarante.

Bah si tu veux ça tu peux toujours faire des structs plutôt que des classes. A partir du moment où c'est immuable, il n'y a plus tant de différences entre les deux (au niveau de l'utilisation du moins).

Sinon c'est vrai que ce genre de truc est assez laborieux à implémenter ; perso j'utilise Resharper depuis longtemps, qui a une fonctionnalité "Generate equality members" assez bien faite.

[DonQuiche]

En fait pour le TryParse, je préfèrerais de loin que ça renvoie un nullable

Ça se défend, ça demanderait souvent une ligne en plus, j'aime bien mon "if (TryParse(out result))".

Le gros chantier de cette version est le compilateur Roslyn, tout le reste est du bonus.

C'est juste.

Perso le truc que j'aimerais bien avoir c'est le "tuple unpacking" des langages fonctionnels

A vrai dire l'un de mes principaux reproches à la prog fonctionelle est le manque de noms dans le code et c'est exactement la raison qui fait que j'utilise très peu les tuples. ^^
Je préfère de loin faire une classe ou une structure avec les champs nécessaires. Les constructeurs primaires sont donc pour moi une bonne chose.

Comment ça ? Tu peux les initialiser inline, avec ou sans constructeur primaire... Tu voudrais pouvoir les initialiser depuis un constructeur normal ?

Tout à fait. Et s'il est toujours possible d'invoquer le constructeur primaire depuis un autre constructeur tu sais comme moi que dans certains cas ce sera insuffisant.

Bah si tu veux ça tu peux toujours faire des structs plutôt que des classes. A partir du moment où c'est immuable, il n'y a plus tant de différences entre les deux (au niveau de l'utilisation du moins).

Malheureusement pour des raisons de performances il faut souvent passer par une classe.

Sinon c'est vrai que ce genre de truc est assez laborieux à implémenter ; perso j'utilise Resharper depuis longtemps, qui a une fonctionnalité "Generate equality members" assez bien faite.

J'ai privilégié de la méta-programmation de mon côté : un attribut sur la classe et un script qui passe derrière pour générer un code dans un fichier distinct.

[la.lune]

On voit que C# s'approche de plus en plus aux langages dynamiques en gardant en même temps son typage static et fort, ça c'est une bonne chose. Je crois qu'il est le seul langage à typage static à fournir la possibilité de faire a.champs à la place de a["champ"], là je suis en pur javascript !

Déjà quand je vois les constructeurs primaires, ça me rappel qu'en fait les constructeur en JavaScript passent de la même manière ça ressemble à une fonction, làbas on commence par "function" et ici par "class", le seul gain de plus en C#6 c'est que l’affectation des valeurs se fait de façon implicite +1.

[Reward]

Merci beaucoup Tom pour ce tour d'horizon des nouveautés.

Pour ma part, je retiendrais surtout la gestion du null lors d'un enchainement du type Obj1.Obj1N.ProprieteX, assez pratique comme écriture, tout en restant "simple".

Car raccourcir pour raccourcir, je ne suis pas toujours fan quand cela diminue quelque peu la fluidité de lecture pour un tiers, peu habitué à des écritures courtes.

[pascalCH]

Idem ca pique un peu.

Une autre chose, mais c'est peut être moi, c'est quoi l’intérêt de çà ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
public int Answer { get; } = 42;

Oui, dommage de ne pas avoir retenue la très élégante forme du Delphi ce qui aurait donné un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public int Answer { get; set; default=42};

[Sehnsucht]

Pas mal toutes ces futures "nouveautés" ; même si certaines ne me paraissent pas si nouvelles quand on a un oeil qui louche sur VB.Net (mais c'est aussi la continuation du rapprochement entre les deux langages)

L'initialiseur de propriété automatique, c'était possible uniquement pour les propriété en lecture/écriture (principalement parce que c'est actuellement le seul type de propriété automatique disponible)
Le "using static" au final revient à étendre le concept (souvent décrié) des méthodes d'un Module utilisables sans qualifier celui-ci [ce n'est pas la même chose non plus, là il faut faire un using sur la classe spécifiquement, alors qu'il suffit en VB.Net d'importer le namespace pour avoir tous les contenus des modules de celui-ci accessibles]
L'accès aux membres indexés, tiens ça aussi je connais déjà il est vrai que c'est une possibilité méconnue et donc très peu employée, tantôt appelée Dictionary Lookup Operator, tantôt Dictionary Member Access ou plus familièrement "Bang Operator" et s'utilisant comme suit :

Code VB :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Dim id As Integer = joe!id
Dim city As String = joe!address!city

Je ne sais encore trop quoi penser des expressions de déclarations, c'est le genre de choses qui, comme les ternaires, peuvent vite devenir imbuvables (et j'aurais préféré une gestion des paramètres out à la F# avec un tuple (bool, value) en retour [mais la gestion/utilisation des tuples est 100 fois meilleure en F# qu'en C# ... à l'heure actuelle tout du moins])
Les filtres d'exception : ahh là j'en connais pas mal qui vont être contents ; sans doute une des rares choses que les dev C# enviaient aux dev VB.Net
La propagation des null : je le rangerais plutôt avec les expressions de déclarations ; c'est le genre que je sens que l'on va voir fleurir et tout envahir et qui sait, la disparition du "." seul à l'horizon
L'opérateur point-virgule ; lui franchement je m'en passerais bien, certes il va permettre de gagner quelques lignes de code, mais à quel potentiel prix ?
Pour le reste, dans l'ensemble plutôt des bonnes choses, peut-être un léger bémol si le choix définitif de l'interpolation se porte sur le préfixe par $ [ça ferait déjà 2 utilisations différentes du même nouveau symbole]

[tomlev]

Le "using static" au final revient à étendre le concept (souvent décrié) des méthodes d'un Module utilisables sans qualifier celui-ci [ce n'est pas la même chose non plus, là il faut faire un using sur la classe spécifiquement, alors qu'il suffit en VB.Net d'importer le namespace pour avoir tous les contenus des modules de celui-ci accessibles]

Oui effectivement ça s'en rapproche un peu. Mais perso je préfère spécifier juste la classe qui m'intéresse, parce qu'importer tous les modules d'un namespace ça peut vite "polluer" l'intellisense, et ça peut facilement créer des conflits de nom.

L'accès aux membres indexés, tiens ça aussi je connais déjà il est vrai que c'est une possibilité méconnue et donc très peu employée, tantôt appelée Dictionary Lookup Operator, tantôt Dictionary Member Access ou plus familièrement "Bang Operator" et s'utilisant comme suit :

Code VB :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Dim id As Integer = joe!id
Dim city As String = joe!address!city

Ah ben tu m'apprends quelque chose, je savais pas que ça existait en VB
Mais au final cette feature a été abandonnée pour C# car les retours étaient assez défavorables.
(il faudra que je mette l'article à jour, mais j'attends que tout ça se stabilise un peu parce que pour l'instant tout change très vite...)

Je ne sais encore trop quoi penser des expressions de déclarations, c'est le genre de choses qui, comme les ternaires, peuvent vite devenir imbuvables

Utilisé à mauvais escient ça peut effectivement devenir illisible, mais il y a plein de cas où ça peut au contraire améliorer la lisibilité.

(et j'aurais préféré une gestion des paramètres out à la F# avec un tuple (bool, value) en retour [mais la gestion/utilisation des tuples est 100 fois meilleure en F# qu'en C# ... à l'heure actuelle tout du moins])

Certes... j'aimerais beaucoup pouvoir écrire var (x, y) = GetPosition() ou quelque chose comme ça. Mais ça n'a pas grand chose avoir avec la feature proposée

Les filtres d'exception : ahh là j'en connais pas mal qui vont être contents ; sans doute une des rares choses que les dev C# enviaient aux dev VB.Net

Effectivement . Je peux pas dire que ça m'ait manqué très souvent, mais occasionnellement je tombe sur un cas où ça aurait été pratique.

La propagation des null : je le rangerais plutôt avec les expressions de déclarations ; c'est le genre que je sens que l'on va voir fleurir et tout envahir et qui sait, la disparition du "." seul à l'horizon

Oui j'ai un peu peur des abus aussi... Mais bon, quels que soient les outils à sa disposition, un mauvais développeur fera toujours du mauvais code, et là c'est juste un outil de plus pour se tirer dans le pied . Pour des développeurs rigoureux, cette feature va juste permettre de simplifier le code...

L'opérateur point-virgule ; lui franchement je m'en passerais bien, certes il va permettre de gagner quelques lignes de code, mais à quel potentiel prix ?

C'est sûr que je m'en servirai certainement pas très souvent... mais à l'occasion ça peut être pratique.

Pour le reste, dans l'ensemble plutôt des bonnes choses, peut-être un léger bémol si le choix définitif de l'interpolation se porte sur le préfixe par $ [ça ferait déjà 2 utilisations différentes du même nouveau symbole]

Non parce que finalement le Indexed member access est abandonné...
Il y a des débats assez virulents au sujet de l'interpolation de chaine sur cette discussion : https://roslyn.codeplex.com/discussions/540869
Ça tourne, entre autres, autour de la culture à utiliser par défaut. A priori ça s'oriente vers la possibilité de définir un préfixe "custom" (en plus de $) pour définir comment l'interpolation va se faire.

[tomlev]

Bonjour,

Un an après la première publication, je viens de mettre à jour l'article sur les nouveautés de C# 6 pour tenir compte de l'évolution de la situation.

En effet, depuis la conférence BUILD en 2014, les choses ont bien changé : le design du langage est maintenant figé et ne devrait plus évoluer. Certaines fonctionnalités qui étaient initialement prévues ont finalement été abandonnées, d'autres ont un peu changé par rapport à ce qui était envisagé. Sauf surprise de dernière minute, l'article devrait maintenant correspondre au langage C# 6 tel qu'il sera lors sa sortie finale.

Bonne (re)lecture !

Lire l'article: les nouveautés de C# 6

[Arnard]

Merci pour la mise à jour. Par contre on a perdu les expressions de déclaration, c'est dommage
Les littéraux binaires ne devaient pas être complexes à mettre en œuvre, dommage que l'implémentation soit reportée.

Pour l'inférence sur les constructeurs, dommage too. Le tuple est parfois trop verbeux !

[tomlev]

Merci pour la mise à jour. Par contre on a perdu les expressions de déclaration, c'est dommage

Oui, mais ça posait de vrais problèmes de scope... Si ça t'intéresse, regarde cette discussion sur CodePlex :
https://roslyn.codeplex.com/discussions/565640

Les littéraux binaires ne devaient pas être complexes à mettre en œuvre, dommage que l'implémentation soit reportée.

Oui, j'étais un peu surpris que ce ne soit inclus... D'un autre côté, la valeur ajoutée est assez faible.

Pour l'inférence sur les constructeurs, dommage too. Le tuple est parfois trop verbeux !

Oui c'est sûr. Pour les tuples, tu peux toujours utiliser la méthode Tuple.Create, qui permet de profiter de l'inférence de type.

Il faut garder à l'esprit qu'une bonne partie des features retirées sont toujours envisagées pour des versions ultérieures du langage, probablement avec un design plus abouti que ce qui était prévu au départ. De plus, le nouveau compilateur va rendre plus facile l'implémentation de nouvelles features, donc à mon avis il faut s'attendre à voir arriver plus souvent de nouvelles versions de C#.

[Tidus159]

Bonjour,

je n'ai pas bien saisi le but du point 1.9 : Opérateur nameof, auriez-vous un exemple ? Est-ce pour faire de la réflexion ?

Merci

[Reward]

Bonjour Tidus.

Non ce n'est pas pour faire de la réflexion.

La réfléxion est évaluée lors de l'exécution.

NameOf est évalué lors de la compilation.

A quoi cela sert il ?

Imagine que tu veuilles utiliser le nom d'une classe dans un log.

Une solution simple consiste à écrire le nom dans le log, comme ceci : Console.WriteLine("MaClasse").

Cependant, si tu changes le nom de ta classe, la refactorisation n'affectera pas la chaine de caractère que tu utilises dans le Console.WriteLine.

C'est là que le NameOf s'avère utile. Tu peux désormais écrire : Console.WriteLine(NameOf(MaClasse). Avec cette méthode, si tu changes le nom de ta classe en MaClasseBis, le refactoring modifiera automatiquement le contenu du NameOf.