JLS :
L' opérateur de priorité la plus faible est la flèche d'une expression lambda (->) , suivie des opérateurs d'affectation.
Suivi dans quelle direction (priorité croissante, priorité décroissante)? - «suivi» signifie que l'affectation a une priorité plus élevée ou une priorité plus faible (par rapport à l'opérateur de la flèche)? Je suppose, en augmentant, parce que "le plus bas" (pour la flèche) signifie absolument le plus bas.
Si je comprends bien, la flèche (->) devrait être tout en bas de ce tableau de priorité des opérateurs de Princeton (qui est en dessous de tous les opérateurs d'affectation), donc la flèche (->) ayant un niveau de priorité 0 (zéro) (selon ce tableau).
Ai-je raison de comprendre?
ExamTray semble dire que la priorité des flèches est au moins la même que celle des affectations ... Plus a précisé que l'associativité des flèches est Gauche-> À-> Droite (contrairement à l'affectation). Je n'ai trouvé aucune citation JLS pour l'associativité des flèches.
J'ai toujours pensé que la priorité d'affectation est principalement la plus basse pour une raison.
la source
The lowest precedence operator is the arrow of a lambda expression.
->
le faible EST , les opérateurs d'affectation ne peuvent pas avoir faible er priorité.IntFunction fo = a->b->a-b; // in test
Implique la priorité / associativité de -> en général. J'ai donc décidé de clarifier -> priorité / associativité place dans l'ensemble du tableau de priorité / associativité parce que je n'étais pas sûr de cela.IntUnaryOperator op; op = x -> x;
est intéressant. Peut(op = x) -> x
- être n'est-il pas pris en compte carop = x
n'est-ce pas une instance valide de laLambdaParameters
production?Réponses:
Notez la phrase précédant le texte JLS cité :
La grammaire du langage Java détermine quelles constructions sont possibles et implicitement, la priorité de l'opérateur.
Même la table de Princeton que vous avez liée aux États:
Ainsi, la grammaire du langage Java n'autorise pas les expressions lambda à gauche d'un opérateur d'affectation et, de même, n'autorise pas les affectations à gauche de l'opérateur
->
. Il n'y a donc aucune ambiguïté possible entre ces opérateurs et la règle de priorité, bien qu'explicitement énoncée dans le JLS, perd tout son sens.Cela permet de compiler, par exemple un tel bijou, sans ambiguïté:
la source
Tout d'abord, expliquons le problème pratique ici.
En supposant que vous ayez une définition comme
La syntaxe suivante est acceptée et fonctionne comme prévu:
Autrement dit, nous avons une fonction d'identité sur
int
affectée à laop
variable. Mais s'il=
avait une priorité plus élevée, nous nous attendrions à ce que Java l'interprète commeCe qui n'est pas syntaxiquement valide, devrait donc être une erreur de compilation. Par conséquent, l'affectation n'a pas, en pratique, une priorité plus élevée que la flèche.
Mais ce qui suit est également OK (supposons qu'il
t
s'agit d'une variable de classe / instance de typeint
):Cela compile et la fonction, si elle est appliquée, affecte la valeur de l'opérande à
t
et la renvoie également.Cela signifie que la flèche n'a pas une priorité plus élevée que l'affectation
t = x
. Sinon, il aurait été interprété commeet clairement, ce n'est pas ce qui se passe.
Il semble donc que les opérations aient la même priorité. De plus, ils sont associatifs à droite. Cela ressort de la grammaire du chapitre 19 de JLS :
Donc, le côté droit du corps lambda nous ramène à
Expression
, ce qui signifie que nous pouvons avoir soit un lambda (de priorité plus élevée) à l'intérieur, soit une affectation (de priorité plus élevée). Ce que je veux dire par "priorité plus élevée", c'est que plus vous approfondissez les règles de production, plus tôt l'expression sera évaluée.Il en va de même pour l'opérateur d'affectation:
Encore une fois, le côté droit de l'affectation nous renvoie à
Expression
, afin que nous puissions avoir une expression lambda ou une affectation là-bas.Ainsi, plutôt que de s'appuyer sur le texte JLS, la grammaire nous donne une description bien définie de la situation.
la source