+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 836
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 836
    Points : 40 629
    Points
    40 629

    Par défaut Les nouveautés de C# 7

    Bonjour,

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

    La version 7 du langage C# s’approche à grands pas, et la liste des fonctionnalités est désormais figée, il est donc temps de les passer en revue.

  2. #2
    Membre actif Avatar de WaterTwelve21
    Homme Profil pro
    Développeur .NET
    Inscrit en
    décembre 2015
    Messages
    179
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : décembre 2015
    Messages : 179
    Points : 272
    Points
    272

    Par défaut

    Je trouve l'arrivée des fonctions locales et surtout le renouveau des tuples très intéressants ! . A peine C#6 arrivée que voila C#7 ( C#8 c'est pour l'an prochain ? ) , les entreprises suivent t-elles le rythme ?
    En tout cas c'est bien de voir l’engouement qu'il y a pour l'amélioration du langage ...
    throw new NoSignatureException();

  3. #3
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    avril 2007
    Messages
    12 832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : avril 2007
    Messages : 12 832
    Points : 23 106
    Points
    23 106

    Par défaut

    les fonctions locales je reste sceptique
    les tuples c'est une très bonne chose selon moi, fini les ref pour retourner un booléen et un string ^^
    les variables out j'aime bien aussi, avoir une ligne de code pour rien du genre int i c'est toujours une ligne de trop
    les littéraux avec le _ c'est plutot pas mal quand on ne manipule pas souvent de l'hexa ou du binaire, j'imagine que quand c'est le cas ca se lit bien sans

    sans opinion sur le reste
    j'irais donc dans le sens que ce sont des évolutions assez mineures, mais c'est surtout parce que valuetype je ne suis pas près de l'utiliser les structures par références il faudrait que je relise plusieurs fois avant de comprendre


    Citation Envoyé par WaterTwelve21 Voir le message
    les entreprises suivent t-elles le rythme ?
    autre débat, auquel j'aurais tendance à dire "clairement non"
    il y en a encore sur vs 2008 ou 2010, même des boites qui peuvent se le permettre (abo msdn par exemple) ne font pas forcément de migration
    surtout parce qu'il y a peu de gens qui doivent s'intéresser aux changements d'un langages et lire ce genre de page
    il faut aimer la technique et l'optimisation (de perf ou de qualité/quantité de code) pour avoir envie d'utiliser des nouvelle fonctionnalités
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  4. #4
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 836
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 836
    Points : 40 629
    Points
    40 629

    Par défaut

    Citation Envoyé par WaterTwelve21 Voir le message
    les entreprises suivent t-elles le rythme ?
    Ça dépend lesquelles... Dans ma boite on a adopté VS2015 et C# 6 très vite après leur sortie, du moins dans mon équipe. En fait, je pense que jusqu'ici, l'adoption des nouvelles versions du langage a été freinée par la nécessité d'acheter une nouvelle version de Visual Studio à chaque fois ; mais j'ai cru comprendre qu'il était prévu que ça change. C# évolue de plus en plus vite, et je ne pense pas que MS pourra continuer à sortir une nouvelle version de VS pour chaque nouvelle version du langage.

    Il est déjà possible, via ce package NuGet, d'utiliser la dernière version du compilateur dans une version plus ancienne de Visual Studio. Par contre, vu que l'IDE lui-même ne supporte pas les nouvelles features, il y aura plein d'erreurs affichées au niveau de l'éditeur, même si ça compile... ce qui réduit un peu l'intérêt.

    Citation Envoyé par Pol63 Voir le message
    les fonctions locales je reste sceptique
    Disons que ça évite les fonctions "helper" qui traînent un peu n'importe où dans le code, qui au fil des modifications se retrouvent loin de la méthode qui les utilise, etc. Ça permet d'avoir un code mieux organisé. Et puis les fonctions locales ont l'avantage, par rapport à des fonctions normales, de pouvoir accéder aux variables et paramètres de la méthode où elles sont déclarées.

    Pour moi un des cas où c'est utile est la validation des arguments pour un itérateur ou une méthode asynchrone. En effet, un itérateur est "lazy", c'est à dire que le corps de la méthode ne commence à s'exécuter que quand on commence à énumérer le résultat, et non lors de l'appel de la méthode. Si bien que ce code ne donne pas le résultat voulu :

    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    void Test()
    {
        var enumerable = Repeat("test", -1); // Pas d'erreur
        using (var enumerator = enumerable.GetEnumerator()) // Toujours pas d'erreur
        {
            enumerator.MoveNext(); // Erreur ici
        }
    }
     
    IEnumerable<T> Repeat<T>(T item, int count)
    {
        if (count < 0)
            throw new ArgumentOutOfRangeException("count must be positive");
     
        for (int i = 0; i < count; i++)
        {
            yield return item;
        }
    }

    Pour que les arguments soient validés immédiatement lors de l'appel, il faut écrire la méthode Repeat comme ceci :

    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    IEnumerable<T> Repeat<T>(T item, int count)
    {
        if (count < 0)
            throw new ArgumentOutOfRangeException("count must be positive");
        return RepeatIterator(item, count);
    }
     
    IEnumerable<T> RepeatIterator<T>(T item, int count)
    {
        for (int i = 0; i < count; i++)
        {
            yield return item;
        }
    }

    Ce qui n'est pas super pratique... Avec les fonctions locales, on peut faire ça :

    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    IEnumerable<T> Repeat<T>(T item, int count)
    {
        if (count < 0)
            throw new ArgumentOutOfRangeException("count must be positive");
     
        IEnumerable<T> Iterator()
        {
            for (int i = 0; i < count; i++)
            {
                yield return item;
            }
        }
     
        return Iterator();
    }

  5. #5
    Membre averti
    Profil pro
    Inscrit en
    avril 2008
    Messages
    303
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2008
    Messages : 303
    Points : 312
    Points
    312

    Par défaut

    Je suis très étonné par le choix de "Deconstruct"
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    public void Deconstruct(out double x, out double y)
    {
        x = this.X;
        y = this.Y;
    }

    Je comprends qu'en interne ils veuillent se reposer sur du C# "ancien" mais pour l'utilisateur final d'aujourd'hui le but des nouveaux "tuples" n'est-il pas justement d'éviter au maximum l'utilisation peu pratique et archaïque de "out" ?

    L'utiliser sous cette forme me semblerait plus judicieuse :
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    public (double x, double y) Deconstruct() => (this.X, this.Y);

    Ensuite la possibilité de déclarer directement une variable "out" est une bonne chose... mais pour moi elle repose toujours sur le mauvais choix de continuer à utiliser "out"

    AMHA une autre direction comme avec un mécanisme d'"exception light" - quand la gestion d'exception classique n'est pas obligatoire ou trop lourde.

    En introduisant par exemple deux nouveaux mots clés, un permettant une sortie incorrecte (sans lancer d'exception) d'une méthode et un autre pour la tester :
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    if (try int i = int.ParseLight(s))
    {
        Console.WriteLine($"La chaine représente un entier de valeur {i}");
    }

    Et comme je réfléchis en même temps que j'écris... je pense même qu'il serait possible de transformer les Parses avec exceptions classiques pour qu'ils fonctionnent... classiquement et aussi dans un mode light se suffisant d'un simple test booléen comme le code au-dessus.

    Sinon avec C# 7 on doit pouvoir écrire cela (bon c'est un peu plus verbeux mais adieux les "out" ):
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    if (!((bool error, int i) = int.ParseLight2(s)).error)
    {
        Console.WriteLine($"La chaine représente un entier de valeur {i}");
    }

    Autrement dans ton switch Pattern matching ça fonctionnerait un "goto Circle c when c.Radius < 5" ?

    Sinon n'y aurait-il pas une petite faute dans ton exemple sur la généralisation du type de retour des méthodes asynchrones ? AMHA la variable "price" en attente n'est pas déclarée puisqu'avant elle est interne au if.

  6. #6
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 836
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 836
    Points : 40 629
    Points
    40 629

    Par défaut

    Citation Envoyé par ijk-ref Voir le message
    Je suis très étonné par le choix de "Deconstruct"
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    public void Deconstruct(out double x, out double y)
    {
        x = this.X;
        y = this.Y;
    }

    Je comprends qu'en interne ils veuillent se reposer sur du C# "ancien" mais pour l'utilisateur final d'aujourd'hui le but des nouveaux "tuples" n'est-il pas justement d'éviter au maximum l'utilisation peu pratique et archaïque de "out" ?
    C'est juste au niveau de la déclaration ; au niveau de l'utilisation, tu n'as pas besoin de out. Et de toute façon c'est juste si tu veux ajouter à une classe la possibilité de la déconstruire, pour les tuples tu n'as rien à faire, c'est déjà fait.

    Citation Envoyé par ijk-ref Voir le message
    L'utiliser sous cette forme me semblerait plus judicieuse :
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    public (double x, double y) Deconstruct() => (this.X, this.Y);
    C'était ma première réaction, mais en fait il y a une bonne raison : avec la syntaxe choisie, tu peux avoir plusieurs méthodes Deconstruct, avec des signatures différentes :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    public void Deconstruct(out double x, out double y)
    {
        x = this.X;
        y = this.Y;
    }
     
    public void Deconstruct(out double x, out double y, out double z)
    {
        x = this.X;
        y = this.Y;
        z = this.Z;
    }
    Avec ce que tu proposes, ce ne serait pas possible, vu que tu ne peux pas avoir deux méthodes qui ne diffèrent que par le type de retour.

    Citation Envoyé par ijk-ref Voir le message
    AMHA une autre direction comme avec un mécanisme d'"exception light" - quand la gestion d'exception classique n'est pas obligatoire ou trop lourde.

    En introduisant par exemple deux nouveaux mots clés, un permettant une sortie incorrecte (sans lancer d'exception) d'une méthode et un autre pour la tester :
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    if (try int i = int.ParseLight(s))
    {
        Console.WriteLine($"La chaine représente un entier de valeur {i}");
    }
    J'aime bien le principe... tu peux le proposer sur le GitHub Roslyn

    Citation Envoyé par ijk-ref Voir le message
    Et comme je réfléchis en même temps que j'écris... je pense même qu'il serait possible de transformer les Parses avec exceptions classiques pour qu'ils fonctionnent... classiquement et aussi dans un mode light se suffisant d'un simple test booléen comme le code au-dessus.
    Le problème des méthodes Parse qui renvoient des exceptions, c'est que les exceptions ne sont pas seulement lourdes en terme de syntaxe, mais aussi en terme de performance. Lancer et catcher une exception, ça coûte cher...

    Citation Envoyé par ijk-ref Voir le message
    Sinon avec C# 7 on doit pouvoir écrire cela (bon c'est un peu plus verbeux mais adieux les "out" ):
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    if (!((bool error, int i) = int.ParseLight2(s)).error)
    {
        Console.WriteLine($"La chaine représente un entier de valeur {i}");
    }
    Oula, pas sûr que ce soit plus lisible... Ce qui serait plus intéressant, c'est une méthode TryParse qui renvoie un Nullable<int>, ça permettrait d'utiliser le pattern matching pour faire ça :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    if (int.TryParse(s) is int i)
    {
        ...
    }

    Citation Envoyé par ijk-ref Voir le message
    Autrement dans ton switch Pattern matching ça fonctionnerait un "goto Circle c when c.Radius < 5" ?
    Non, ça marche pas. Tu peux toujours faire un goto vers un case <Constante>, mais pas vers un case <Type>.

    Citation Envoyé par ijk-ref Voir le message
    Sinon n'y aurait-il pas une petite faute dans ton exemple sur la généralisation du type de retour des méthodes asynchrones ? AMHA la variable "price" en attente n'est pas déclarée puisqu'avant elle est interne au if.
    Non non, c'est correct. Pendant la phase de design il y a eu pas mal de discussions sur le scope d'une variable déclarée comme ça, mais la rendre interne au if posait trop de problèmes. Exemple type de pourquoi c'est problématique :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    if (!int.TryParse(s, out int i))
    {
        // i est défini, mais ça valeur n'a pas de sens puisque TryParse a échoué
    }
    else
    {
        // TryParse a réussi, mais i n'est pas défini
    }
    Donc au final le scope de la variable est le scope parent du if.

  7. #7
    Membre averti
    Profil pro
    Inscrit en
    avril 2008
    Messages
    303
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2008
    Messages : 303
    Points : 312
    Points
    312

    Par défaut

    Citation Envoyé par tomlev Voir le message
    C'était ma première réaction, mais en fait il y a une bonne raison : avec la syntaxe choisie, tu peux avoir plusieurs méthodes Deconstruct, avec des signatures différentes
    Ah oui merci !

    Citation Envoyé par tomlev Voir le message
    Le problème des méthodes Parse qui renvoient des exceptions, c'est que les exceptions ne sont pas seulement lourdes en terme de syntaxe, mais aussi en terme de performance. Lancer et catcher une exception, ça coûte cher...
    Mais c'est exactement ce que je sous entendais : lourdes dans tous les sens

    C'est pourquoi j'imagine qu'en interne les méthodes traitées avec "exceptions lights" auraient un code optimisé et différent. Leurs exceptions retirées et remplacées pour une sortie de fonction classique... une seconde sortie comme je l'explique ici.

    J'ai un peu modifié mon "try" après tes précisions sur le scope des variables "out" pour le rendre plus général par exemple si l'on souhaite sortir un code d'erreur ou n'importe quoi - qui n'a absolument pas besoin d'être de type "Exception".

    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    try int i = int.Parse(s) otherwise i = 0;
     
    try double j = double.Parse(s) otherwise return;
     
    try int k = int.Parse(s) otherwise Console.WriteLine("impossible à parser"); // Erreur à la compilation car 'k' n'est pas toujours défini (pour la suite du code)
     
    try DX.DrawTriangles(vertices) otherwise(int error) { Console.WriteLine("Erreur dans le code n°" + error);  return; }

    Citation Envoyé par tomlev Voir le message
    J'aime bien le principe... tu peux le proposer sur le GitHub Roslyn
    J'aimerai bien. C'est dommage de rencontrer ici si peu de personnes le maîtrisant (dont moi). Et je ne trouves vraiment pas beaucoup d'exemples varié sur le sujet.

    Citation Envoyé par tomlev Voir le message
    Non, ça marche pas. Tu peux toujours faire un goto vers un case <Constante>, mais pas vers un case <Type>.
    Je m'y attendais et même le souhaitais

    Ils auraient mieux fait de l'implémenter loin de ce "switch" sans les ":" et "break".

  8. #8
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 836
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 836
    Points : 40 629
    Points
    40 629

    Par défaut

    Citation Envoyé par ijk-ref Voir le message
    J'aimerai bien. C'est dommage de rencontrer ici si peu de personnes le maîtrisant (dont moi). Et je ne trouves vraiment pas beaucoup d'exemples varié sur le sujet.
    Maîtriser quoi ? Je suggérais juste de proposer l'idée, pas de l'implémenter (c'est certainement pas simple à implémenter, et même si tu veux le faire, ça sert à rien de se lancer dans un tâche aussi grosse avant de s'être mis d'accord sur le design exact).

    Citation Envoyé par ijk-ref Voir le message
    Ils auraient mieux fait de l'implémenter loin de ce "switch" sans les ":" et "break".
    Peut-être... ça a été envisagé d'ailleurs. Je crois qu'ils ont préféré garder le switch parce que les gens y sont habitués. Personnellement je trouve que switch est un des trucs les plus horribles de C#. Il a été hérité de C presque tel quel (en ajoutant juste l'interdiction du fallthrough pour le rendre un peu plus sûr), avec les mêmes défauts de design. Ce qui m'agace le plus c'est le fait qu'une variable déclarée dans un case est en fait dans le scope du switch, ce qui fait qu'on ne peut pas déclarer une autre variable du même nom dans un autre case.

  9. #9
    Membre averti
    Profil pro
    Inscrit en
    avril 2008
    Messages
    303
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2008
    Messages : 303
    Points : 312
    Points
    312

    Par défaut

    Citation Envoyé par tomlev Voir le message
    Maîtriser quoi ? Je suggérais juste de proposer l'idée, pas de l'implémenter (c'est certainement pas simple à implémenter, et même si tu veux le faire, ça sert à rien de se lancer dans un tâche aussi grosse avant de s'être mis d'accord sur le design exact)..
    Ah oui j'étais parti... loin devant


    Ne trouverais-tu pas intéressant une rubrique Roslyn sur ce Forum ? Histoire de parler entre nous avant d'une implémentation possible et peut être mieux délimiter nos idées. Penses-tu que cela intéresserait d'autres que nous ?

    Parce que franchement j'ai souvenir d'avoir émis il y a quelques années l'intérêt d'un "(Type1 x, Type 2) f(Type3 z, Type4 w)" qui fut noyé par des intervenants expliquant sa non-pertinence plutôt qu'autre chose.

    Citation Envoyé par tomlev Voir le message
    Peut-être... ça a été envisagé d'ailleurs. Je crois qu'ils ont préféré garder le switch parce que les gens y sont habitués. Personnellement je trouve que switch est un des trucs les plus horribles de C#. Il a été hérité de C presque tel quel (en ajoutant juste l'interdiction du fallthrough pour le rendre un peu plus sûr), avec les mêmes défauts de design. Ce qui m'agace le plus c'est le fait qu'une variable déclarée dans un case est en fait dans le scope du switch, ce qui fait qu'on ne peut pas déclarer une autre variable du même nom dans un autre case.
    Pareil ce "switch" me donne envie de vomir

  10. #10
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 836
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 836
    Points : 40 629
    Points
    40 629

    Par défaut

    Citation Envoyé par ijk-ref Voir le message
    Ne trouverais-tu pas intéressant une rubrique Roslyn sur ce Forum ? Histoire de parler entre nous avant d'une implémentation possible et peut être mieux délimiter nos idées. Penses-tu que cela intéresserait d'autres que nous ?
    A mon avis c'est pas très utile. Toutes les discussions sur le design du langage se passent sur GitHub, je vois pas trop l'intérêt d'en discuter dans notre coin.

    Citation Envoyé par ijk-ref Voir le message
    Parce que franchement j'ai souvenir d'avoir émis il y a quelques années l'intérêt d'un "(Type1 x, Type 2) f(Type3 z, Type4 w)" qui fut noyé par des intervenants expliquant sa non-pertinence plutôt qu'autre chose.
    Oui je vois ce que tu veux dire, mais dans ce que j'ai vu, une idée est rarement rejetée sans une bonne raison. Après il faut voir aussi qu'il y a plein de features qui seraient intéressantes, mais on peut pas tout faire, et certaines sont plus prioritaires que d'autres (en fonction de la demande, de la popularité de l'idée, de la vision du comité de design du langage, etc). En plus, il faut faire gaffe à pas partir dans tous les sens, le langage doit garder une certaine cohérence, sinon ça va finir par ressembler à C++ (qui selon moi est à la base un excellent langage, mais qui est devenu au fil des années tellement compliqué que je comprends plus rien quand je lis du code C++ moderne)

  11. #11
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    avril 2007
    Messages
    12 832
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : avril 2007
    Messages : 12 832
    Points : 23 106
    Points
    23 106

    Par défaut

    Citation Envoyé par tomlev Voir le message
    A mon avis c'est pas très utile. Toutes les discussions sur le design du langage se passent sur GitHub, je vois pas trop l'intérêt d'en discuter dans notre coin.
    surtout à 2 ^^
    (déjà qu'on est que 3 à parler des nouveautés ...)

    Citation Envoyé par tomlev Voir le message
    En plus, il faut faire gaffe à pas partir dans tous les sens, le langage doit garder une certaine cohérence, sinon ça va finir par ressembler à C++ (qui selon moi est à la base un excellent langage, mais qui est devenu au fil des années tellement compliqué que je comprends plus rien quand je lis du code C++ moderne)
    oui, j'ai cru comprendre qu'il y a eut plusieurs grosses évolutions avec des différences fondamentales, et qu'on peut mixer le tout pour noyer encore plus ^^
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  12. #12
    Membre averti
    Profil pro
    Inscrit en
    avril 2008
    Messages
    303
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2008
    Messages : 303
    Points : 312
    Points
    312

    Par défaut

    Citation Envoyé par tomlev Voir le message
    A mon avis c'est pas très utile. Toutes les discussions sur le design du langage se passent sur GitHub, je vois pas trop l'intérêt d'en discuter dans notre coin.
    Parce que ce serait en français et je voyais plus cela comme une première ébauche et l'affinage d'une idée "dans notre coin" pour ensuite mieux la transmettre sur GitHub. Mais il est vrai aussi que nous avons l'air trop peu ici à nous y intéresser pour y développer quoi que ce soit de pertinent

  13. #13
    Membre averti
    Profil pro
    Inscrit en
    avril 2008
    Messages
    303
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2008
    Messages : 303
    Points : 312
    Points
    312

    Par défaut

    J'ai vu ici - Roselyn patterns - que l'utilisateur pourra définir l'opérateur "is" dans un classe static

    Je me demande s'il le sera aussi dans une classe normale pour avoir directement :
    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    var s = "123";
    if(s is int i) Console.WriteLine(i);

  14. #14
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 836
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 836
    Points : 40 629
    Points
    40 629

    Par défaut

    Tu parles de l'exemple avec Polar/Cartesian? Je pense que c'est juste un exemple, la spec a pas l'air finalisée concernant l'opérateur is "user-defined". Je ne pense pas que ce sera limité aux classes statiques.

    Par contre ton exemple n'est sans doute pas une bonne idée. Si je fais ça :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    var s = "123,456";
    if(s is int i) Console.WriteLine(i);
    En français, la condition serait fausse, car le nombre ne serait pas entier. Par contre en anglais la virgule est le séparateur de milliers, donc la condition serait vraie... Bref, le même code fonctionnerait différemment selon la culture courante.

  15. #15
    Membre averti
    Profil pro
    Inscrit en
    avril 2008
    Messages
    303
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2008
    Messages : 303
    Points : 312
    Points
    312

    Par défaut

    Bonjour puisque c'est aussi un peu la suite de cette conversation sur une meilleure approche de "TryParse" je mets en lien ma nouvelle réponse : https://www.developpez.net/forums/d1...e/#post9274591

Discussions similaires

  1. [CR10]Quelles sont les nouveautés de la version 10 ?
    Par osoudee dans le forum SAP Crystal Reports
    Réponses: 3
    Dernier message: 11/11/2004, 16h37

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo