Reprise du message précédent :

Je pense que c'est à ceci que cela se réfère:

sur le modèle, comme le postait quelqu'un sur reddit

(bon, il y a surement aussi pas mal de diffs)
A+,

 
Ça vient surtout des fibres (les fibres, c'est bon, mangez-en).

OK, ce sont des greenlets/coroutines, en fait.

La conf du gars qui a écrit ça m'a fait comprendre qu'en fait, je connaissais vraiment rien aux coroutines malgré un peu d'utilisation en Python.
Leur utilisation pour remplacer une machine d'état, j'avais jamais imaginé.

Je n'ai pas vu derelict figurer dans ce topic, pourtant, c'est un module de fort utile.
http://www.dsource.org/projects/derelict

Tombé dessus en cherchant des bindings D pour SDL.
 
A+,

Damned, faire plier Walter, c'est vraiment difficile !
 
http://d.puremagic.com/issues/show_bug.cgi?id=6857

Dans ce cas la, il suffirait peut être d'étendre le langage des contrats avec un "static in" (probleme solved, it just needs to be implemented ) pour choisir le type de vérification a la compilation/dynamique...
A+,

T'as intérêt à avoir des arguments bien rodés, ouais.

Surtout que Walter ne fait qu'appliquer les règles de B Meyer clairement définies pp 47-48 du document que deadalnix a trouvé, http://se.ethz.ch/~meyer/publicati [...] ntract.pdf
(Mais en fait en relisant a deux fois, deadalnix a peut être raison, en fait le cas dont il parle n'est pas explicitement mentionné)
EDIT: je viens de finir de lire le débat. deadalnix  wins!    
A+,

En y repensant, il y a un truc pas net:
 

Pourquoi (A.foo OR B.foo) et pas simplement B.foo, puisqu'on travaille avec des objets B.
Est-ce que ça a un sens d’appeler fizzbuzzB(b) sans erreur sur un B b qui ne vérifie pas B.foo, mais seulement A.foo?
Bon, je peux comprendre qu'on agisse ainsi au cas ou on n'a pas de contraintes de contrat supplémentaires dans B et qu'on veut "hériter" de celles de A, mais ne devrait-on pas plutôt avoir (A.foo AND B.foo)'s in contract is valid. Ou bien quelque chose du style "Si B a des contraintes explicites elles doivent être vérifiées, sinon celles de A doivent être vérifiées".
 
A+,

Lorsque tu surcharges une méthode, elle doit être covariante avec la méthode surchargée.
 
C'est à dire que tout appel vers des fonctions qui est valide sur une object de type A doit aussi l'être sur un object de type B, mais B peut étendre les appel possibles par rapport à A.
 
En d'autres termes, tout appel valide sur un object de type A doit être valide sur un object de type B. Ceci implique qu'une précondition ne peut qu'étendre ce qu'accepte une méthode, et pas restreindre.
 
Or, sans mettre un ou entre les précondition, le contract sur B peut réduire ce que B.foo accepte comme entrée valide. Ceci serait une violation des principes de base de la programmation orientée objet.
 
D'un point de vue plus pratique, B.foo doit quoi qu'il arrive supporter les entrée qui valident le contrat de A, donc il n'y a pas lieu d'empêcher cela dans le cas ou le type est connu.

Si le contrat est validé avant de faire l'appel, je vois pourquoi en effet.
A+,

Les préconditions sont vérifiées avant l'appel. Les postconditions après. Au contraire, les postconditions doivent toutes êtres respectées. Et de façon polymorphiques car ce contrat exprime des contrainte pour la fonction appelée, et non la fonction appelante.

C'est dingue le boulot qu'il abat, Kenji Hara. Le nombre de bugs qu'il corrige.

Haha, j'ai une seconde entrée dans http://erdani.com/tdpl/errata/ (j'en ai soumis bien plus, mais d'autres sont passé avant moi ).
 
Et yep, Kenji Hara est un bon gars Walter aussi hein, faut pas déconner.
 
Par contre, coté druntime j'ai deux pull request qui datent de Matusalem qui moisissent et Alex Rønne Peterson en a 6 ! Ça a plus de mal à mouliner de ce coté.
 
Sinon, un article sur les Voldemort types : http://www.drdobbs.com/blogs/cpp/232901591
 
Même si avec l'UFCS le dernier exemple serait plus élégant sous la forme :
 

Nan mais Walter, il est hors catégorie.

Lien sans avoir à s'inscrire: http://www.drdobbs.com/article/pri [...] onName=cpp

Et

peut aussi être simplifié en:

J'ai pas capté grand chose aux Voldemort types, je dois dire.
Ca m'a l'air sympa et tout, mais c'est pas très clair dans ma tête. Sur reddit, y'en a qui disent que ça n'a rien de nouveau et qu'on peut faire la même chose depuis longtemps en C++

En tout cas, plus ça va, plus on se rapproche de la simplicité de la syntaxe de Python.

J'essaye de faire du lobbying pour que tous les statements deviennent des expressions (éventuellement de type void) et que les comma expression soient deprecated pour être recyclées en tuples. Si les tuples ignorent les expressions de type void et s'auto unpack, ça ne casserait même pas beaucoup de codes.
 
Ça ouvre des portes comme :
 
int, int foo();
 
(int a, int b) = foo();
 
Et ça simplifierait grandement aussi les AST macros (en chantier depuis l'an 40).

http://javascriptweblog.wordpress. [...] -fat-city/
 
Javascript veut copier notre syntaxe pour les closures
 
On ferait bien de copier la leur pour les named expressions, mais ça nécessite encore les modifs citées plus haut, sans quoi l'AST va devenir infernal.

La on est exactement sur la même longueur d'onde.
Perso, ça me gênerais pas d'avoir plutôt (int, int) foo(); mais bon, pourquoi pas int, int foo();
l'essentiel étant qu'on autorise (a, b) = foo(); mais pas (comme en go, ce qui me parait un nid a problèmes) a, b = foo();
 
A+,

Pourquoi est-ce un nid à problèmes, à partir du moment ou l'opérateur comma est deprecated ?

En fait, le tuple pourrait être implémenté comme une struct passée sur la pile, non ?

Du coup, je verrais bien quelque chose comme:

avec les syntaxes suivantes autorisées:
 

Avec les tuples, j'ai l'impression que D aurait toutes les constructions pour pouvoir porter du code Python idiomatique facilement. Ca donne une bonne indication de la puissance du langage.
edit: ah oui l'introspection est très limitée, par contre, mais en dehors de ça, c'est impressionnant.

 
C'est pas clair parce que ça dépend de la précédence des opérateurs. En fonction ça peut être ou bien une assignation de tuple, ou bien un erreur de type :
 
int a, int b = foo(); => (int a, int b) = foo(); ou bien int a, (int b = foo());
 
Le second est valide aussi grammaticalement, mais b n'a pas le bon type. Si on et auto pour éviter ladite erreur, ça donne :
 
int a, (auto b = foo()); qui évalue à un tuple de 3 entiers. Maintenant sans les parenthèses, int a, auto b = foo(); On a un tuple de 2 ou trois entiers la ?
 
En fait, la sémantique du tout dépend de la précédence entre « , » et « = », et c'est facilement ambigu pour l'humain (pas pour le parser).

 
Si ça peut te consoler, je travaille sur les AST macro depuis un moment déjà.

Merci.
Tiens, j'ai édité mon post.
Que penses-tu de ma proposition ?
En gros, le tuple est une struct, et on autorise quelques syntaxes supplémentaires.

 
Transformer les statement en expression et recycler la virgule est plsu clean. Ta proposition en peut pas se faire sans transformer les statement en expression, par contre ne nécessite pas de reprendre la virgule.
 
À mon avis c'est moins bien car ça introduit une nouvelle syntaxe, et que par ailleurs, la virgule est déjà utilisée pour exprimer des tuples (les paramètres des fonction qu'on appelle, qu'est ce que c'est hein ?? D'ailleurs, les comma expression en marchent pas dans ce cas).
 
EDIT: par contre, yep, c'est un truc du genre que le compilo va générer à la fin.

J'ai pas compris la transformation statement --> expression. (je ne suis pas un spécialiste des langages)

C'est pas faux, mais si on part la-dessus, on se ferme la porte d'une évolution possible (en 2020) vers les paramètres nommés.
edit: en fait, si on considère que le tuple des paramètres de la fonction est une structure, on est pas loin des paramètres nommés

Ma proposition a plusieurs avantages à mes yeux:
 - on n'introduit pas un nouveau type d'objet "tuple", une struct fait l'affaire, conceptuellement, on est en terrain connu,
 - la syntaxe me parait claire,
 - il n'y a même plus besoin de déprécier l'opérateur comma, mais tu as raison, le déprécier permet d'éviter les ambiguités que tu as données.

Voila. Ne pas mettre les parenthèses, c'est le genre de choses qui est plus source de problème par suite d'une faute de frappe pas évidente à la relecture, qu'elle n'apporte de bénéfices en nb de signes tapés.
A+,

 
Déprécier l'opérateur comma est de tout façon nécessaire. C'est une source d'erreur importante.

Juste pour signaler un post au sujet de D (& Go) sur Dr Dobbs:
 
http://www.drdobbs.com/cpp/232901652

http://astoriaseminar.com/sessions.html  

http://klickverbot.at/blog/2012/05/purity-in-d/
 
Un très bon article pour expliquer la notion de pureté en D, qui est un peu différente de celle que l'on trouve dans d'autres langages.

Alors, tout le monde à fuis le topic ?
 
En tout cas, linux-fr parle de D : http://linuxfr.org/news/le-langage-d--2

Il commence à faire chaud on passe à la bière.

Pas terrible, le tutoriel. On ne peut pas dire qu'il donne envie de découvrir le langage.

Qu'est ce que tu aurais fait différemment ?

Ben vu l'espace limité, j'aurais présenté les features les plus intéressantes du langage, plutôt que les boucles, dont tout le monde se fout, via quelques exemples commentés.

Je ne sais pas trop quel est le public de linuxfr. Si c'est des débutants, ils risquent de ne pas comprendre.
 
Sinon c'est une bonne approche.

size_t partout, on se demande pourquoi, @safe pure nothrow introduit dès le début (pourquoi ?) et non expliqué, puis un exemple avec des types paramétrés qui sort d'on ne sait où et qui ne marche qu'avec des nombres, et ensuite il fait un paragraphe sur if... then... else ... en fait cette news est une catastrophe.
Même l'exemple de foreach est foireux, et ne montre pas l'intérêt de l'inférence de type par rapport à la syntaxe Java par ex.

linuxfr aussi faut pas s'attendre à du pulitzer

deadalnix, j'ai pas trop saisi, c'est quoi la débâcle avec const ?

Bon, c'est un peu compliqué.
 
D const est différent de const en C ou C++. Il est transitif, ce qui impose que tout ce qui est atteint à travers quelque chose de const est const. Cela est fait pour répondre à diverses problématique liée au multithreading et à la programmation fonctionnelle, je ne vais pas revenir la dessus, le pourquoi n'est pas important ici, si ce n'est de savoir que c'est justifié.
 
La classe Object défini des fonction comme opEquals (qui sert à tester si deux object sont égaux). La grande question est de savoir si cette fonction doit être const ou non.
 
Si cette méthode n'est pas const, alors on ne peut tester l'égalité d'objects const ou immutables, ce qui est somme toute un problème.
 
Mais si on la définit const, alors d'autres soucis se présente (par exemple, il devient impossible de mettre les résultat en cache car const est transitif).
 
Ces méthodes sont nécessaires pour certaines fonctions de base du langage, par exemple les tableau associatifs.
 
Au final, ces méthodes vont être virées d'object (quel sens peut de toute façon avoir if(new FtpConnection(xxx) > new mployee("bob" )) ? ) et le problème va être résolu grâce à la sainte puissance des templates.
 
En pratique, cela casse très peu de code et a donc été jugé acceptable.
 
Cela a créé un autre sujet, qui est à mon sens important, c'est le fait qu'il faille un système de release plus complexe que l'actuel, pour permettre de supporter l'ancienne façon de faire pendant un temps.

OK, merci, j'ai lu tout ça. La solution retenue, c'est effectivement de virer les 4 méthodes opEquals, hashCode, opCmp et je ne sais plus quoi d'autre (toString() ?) de Object.
Ceci dit, si opCmp n'a pas de sens dans le cas général (elle devrait avoir un sens dans le cas d'objets implémentant l'interface Comparable), opEquals et hashCode ont tjrs un sens sur Object. C'est pourquoi l'idée d'une superclasse RawObject ne me parait a priori pas stupide.
Une partie des classes dériverait de RawObject tandis qu'une autre dériverait d'Object (qui lui-même dérive de RawObject).

Smalltalk, welcome back!
A+,