Je propose de stripper la declaration des fonctions pour qu'elles
soient de la sorte :
Funtion : Type Identifier Params InStmtOpt OutStmtOpt BlockStmt ;
InStmtOpt : "in" BlockStmt | epsilon ;
OutStmtOpt : "out" BlockStmt | epsilon ;
La difference est que l'on ne peut pas placer InStmt apres OutStmt et
qu'il n'y a plus de "body" pour le corps de la fonction (celui-ci
n'avait aucune utilite non ?).
Rappel : les bloques "in" et "out" sont des bloques de programmation
par contrat : on y place des asserts pour verifier la validite des
arguments et valeur de retour. Le contrat de sortie est conserve lors
de l'heritage.
Cette modification s'applique egalement a une fonction templatee.
--
Alexandre Bique (bique.a...@gmail.com)
Epita 2009 - GISTR - Yaka
Port. +336 19 42 85 26
Iop,
> La difference est que l'on ne peut pas placer InStmt apres OutStmt et
> qu'il n'y a plus de "body" pour le corps de la fonction (celui-ci
> n'avait aucune utilite non ?).
C'est bien mon avis :p
Je suis également pour qu'on ne puisse plus placer in après out.
Cependant, pour le body c'est une décision qui casse la compatibilité
entre dcompiler et les autre compilateurs de D, vu que pour compiler
avec dcompiler il ne faudra pas mettre body, et que pour compiler avec
les autres il faudra le mettre.
Supprimer les [] après les identifiants n'avait pas un tel impact :
ici on rend impossible la réalisation de code portable :(
Je ne suis donc pas favorable à ce dernier point.
Tchoutchou,
--
Arkanosis
Actuellement le mot clef `body' est optionnel dans notre grammaire.
Si on doit se preoccuper de la compatibilite avec le language D a
chaques fois, nous ne ferons que nous limiter et nous passerons a cote
de belles choses. De toute facons je pense qu'on divergera tot ou tard
du language D a un tel point qu'il ne sera plus question de
compatibilite. Autant le faire des maintenant. Il y aura surement un
moyen de faire un convertisseur qui convertira du D vers notre
language.
Par exemple une question qu'il va falloir regler prochainement est le
cas du mot clef `const'. Pour faire des methodes const et passer des
arguments const.
De mon point de vue c'est l'idéal.
> Si on doit se preoccuper de la compatibilite avec le language D a
> chaques fois, nous ne ferons que nous limiter et nous passerons a cote
> de belles choses. De toute facons je pense qu'on divergera tot ou tard
> du language D a un tel point qu'il ne sera plus question de
> compatibilite. Autant le faire des maintenant. Il y aura surement un
> moyen de faire un convertisseur qui convertira du D vers notre
> language.
Pour cela il faudra encore le parser :p
> Par exemple une question qu'il va falloir regler prochainement est le
> cas du mot clef `const'. Pour faire des methodes const et passer des
> arguments const.
Pour les arguments const : "in" en D 2.0
Sinon const est une classe de stockage en D, pas un modificateur de
type comme en C++; il faudrait donc autre chose dans ce cas.
--
Arkanosis
>> Si on doit se preoccuper de la compatibilite avec le language D a
>> chaques fois, nous ne ferons que nous limiter et nous passerons a cote
>> de belles choses. De toute facons je pense qu'on divergera tot ou tard
>> du language D a un tel point qu'il ne sera plus question de
>> compatibilite. Autant le faire des maintenant. Il y aura surement un
>> moyen de faire un convertisseur qui convertira du D vers notre
>> language.
> Pour cela il faudra encore le parser :p
D'ici la il faudra deja avoir un compilo qui tourne bien et qui est bien teste.
>> Par exemple une question qu'il va falloir regler prochainement est le
>> cas du mot clef `const'. Pour faire des methodes const et passer des
>> arguments const.
> Pour les arguments const : "in" en D 2.0
> Sinon const est une classe de stockage en D, pas un modificateur de
> type comme en C++; il faudrait donc autre chose dans ce cas.
Je vais regarde en detail ce que propose le D 2.0, peut-etre qu'on
pourrait ouvrir un autre thread au sujet des const.