Eyyub a écrit 10 commentaires

Typiquement,

int tab[] = [1, 2, 3];

tab = tab + 1;

signifie, pour un être humain normal, [2,3,4]. Alors oui, c'est certain, un cerveau est >assez flexible pour comprendre que ça n'est pas le cas et d'apprendre comment faire une boucle à la place

Pas besoin de faire une boucle :
int[] array = [1, 2, 3];
array[] = array[] + 1; // [2, 3, 4]

C'est joli hein ? :D

Il n'y a quasiment rien qui n'est plus valable(et ce n'est pas au niveau des specs du langage, mais de Phobos), néanmoins le livre contient un certain nombre d'erreurs que tu peux consulter ici.

Depuis le livre grosso modo, je dirai qu'il y a eu l'ajout des UFCSs(je ne suis pas sur mais je pense qu'il les a utilisé dans le livre(avant qu'ils implémentent le truc)), et la nouvelle syntaxe lambda C#-like(on peut utiliser l'ancienne encore) :

void main()
{
    auto foo = delegate string(string bar) { return bar; }; // comme dans le livre
    auto foo2 = (string bar) => bar; // une autre possibilité maintenant
    writeln(foo("bar"), foo2("bar2")); // output : barbar2
}

Voilà en gros.

Sinon depuis le livre ils ont implémenté @property, @safe, alias this est utilisable maintenant(avant y'avait des gros bugs, maintenant y'en a moins), je sais pas ce qu'il en est de inout j'ai encore jamais eu le plaisir de l'utiliser.

Pour ceux qui aimerait en savoir plus à propos de D, il y a d'autres articles abordant d'autres features intéressante : Cool features of the D language, Three unlikely successful features of D(Andrei Alexandrescu, video talk LangNEXT 2012), The D programming language(Walter Bright, video talk LangNEXT 2012), What does C++ do better than D.

Non absolument pas, tu te doutes bien que si les programmeurs D sont contents d'immutable c'est parce qu'ils aiment pas trop le const de C++.

Le const de C++ n'est pas transitive, tandis que le const et l'immutable de D le sont.
Le const de C++ n'offre quasiment aucune garantie au niveau de la thread-safety.

Le const de C++ se rapproche plus du const de D(avec notamment la notion de transitivité comme grosse différence), certainement pas d'immutable. :)

En règle générale, std.stdio n'est pas du tout apprécié par la communauté.
Apparemment un nouveau module std.io va bientôt(entendre par là quelques mois ou versions) être écrit, à vocation d'être moins buggé(et aussi pour rajouter de nouvelles fonctions mais bon), pour rendre remplacer std.stdio sur le long terme(j'imagine que dans un premier temps il sera marqué deprecated).

Quand une data est marquée immutable, elle ne pourra jamais changer, elle sera de même valeur durant toute l’exécution du programme, comme dans un langage fonctionnel.
Au niveau de la concurrence de D2, immutable permet d'être thread-safe.
Donc vu que le compilo sait que la data est immutable, il peut optimiser en fonction.

Tandis que const donne juste la garantie qu'une référence vers la data marquée const ne changera pas celle ci(la référence), par contre une autre référence vers le même objet est en droit de le modifier.(alors qu'avec immutable non)

En gros immutable est à utiliser quand la data doit rester la même du début à la fin de l'éxécution et const est plus pour garantir que la data ne sera pas modifier avec l'identificateur marqué const.(en paramètre d'une fonction par ex.)

void main()
{
    int[] a = [1, 2, 3];
    immutable(int)[] b = a; //Error: cannot implicitly convert expression (a) of type int[] to immutable(int)[]
    b[0] = 0; // ne compilera oh grand Dieu jamais
}

void main()
{
    int[] a = [1, 2, 3];
    const(int)[] b = a; // compile
    a[0] = 0;//compile
    b[0] = 0;//compile pas
}

Ceci t'expliquera mieux que moi ;)

Certes, mais en terme d'optimisations ?

Les bindings les plus utilisables sont, pour moi, GtkD(qui est un wrapper OO, même si vu le manque de doc c'est galère à utiliser) et Derelict2(une collection de bindings dynamiques pour le dev de JV), il y a Derelict3 qui commence à grossir petit à petit mais c'est déjà utilisable. ;)

La dépêche est bien rédigé, elle présente bien la facilité du langage.
Seulement, je trouve que la fonction avec les delegate :

pure size_t f( in size_t delegate(size_t) pure dg1, in size_t delegate(size_t) pure dg2) {
return dg1( x ) + dg2( x );
}

est trop verbeuse, surtout qu'en soit cela n'apporte rien en terme d'optimisations ou autres.
J'aimerai bien que tu expliques si @safe pure nothrow @trusted @system, apporte quelque chose en terme d'optimisations ou si c'est pour faire joli ? (j'ai jamais compris à quoi ça servait en pratique :d)

Sinon tu aurais pu parler des templates constraints, des mixin et de la CTFE aussi, c'est quand même les grosses features de D.

Cool en tout cas,

immutable permet une plus grande sécurité que const, c'est une des directions majeurs de D2 par rapport à D1.

Sinon pour size_t, non c'est pas vraiment courant dans les sources que tu trouveras, j'avoue que ça fait pas très idiomatique.
C'est juste la façon de coder de l'auteur. :)