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

[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.