À mesure que la prise en charge des méthodes d’interface par défaut est presque terminée, des problèmes potentiels ont été soulevés. Bien que beaucoup ait été accompli, il s'agit d’une fonctionnalité complexe et de nombreux détails n'ont pas encore été définis. Mais pour commencer, voici quelques-unes des questions résolues.
Les champs statiques et const seront autorisés dans les interfaces.
Les opérateurs autres que == et !=, peuvent être implémentés dans les interfaces. Les opérateurs définis au niveau de la classe ont toujours la priorité sur les opérateurs définis dans l’interface, même si ces derniers sont plus spécifiques. De même, les opérateurs applicables dans une interface masquent les opérateurs dans l'interface de base.
Il est maintenant possible de sauter des classes lors de l'appel d’une méthode de classe de base, en confirmant l'instruction ci-dessous.
Nous pensons avoir approuvé l'utilisation de la nouvelle syntaxe base(Type), où Type est un type de classe (par exemple, ignorer une base et appeler la base de votre base), mais nous devrions le confirmer explicitement. Nous devons également confirmer que la base(Type).M() peut faire référence à un membre non virtuel M. Nous devons également confirmer qu'il existe une exigence d’accessibilité : le M trouvé par ce lookup doit être accessible là où l'invocation a lieu (c'est-à-dire contrainte de name-lookup habituelle).
Des doutes subsistent quant à la possibilité de déclarer des méthodes protégées dans les interfaces, même si cela reste provisoirement approuvé.
Lorsqu'une classe implémente une méthode, mais que sa sous-classe la marque comme abstraite, on parle de "reabstraction". Ceci est nécessaire pour l'interopérabilité Java, mais la syntaxe exacte n'est toujours pas réglée. La question est essentiellement de savoir si le mot clé abstract est requis ou non. En outre, ils "doivent s'assurer que [l'équipe] d'exécution accepte de procéder à la réabstraction".
Les propriétés normales dans les interfaces sont abstraites, même si elles ressemblent à des propriétés implémentées automatiquement dans les classes. Mais si la propriété est statique, elle ne peut pas être abstraite. Cela signifie-t-il qu'une propriété statique déclarée dans une interface est implémentée automatiquement par défaut ?
Les méthodes partielles dans les classes sont supposées être privées, car elles n'ont pas de modificateur d'accessibilité. Mais dans une interface, un modificateur d'accessibilité manquant implique que la méthode est publique. Quelle est la règle pour les méthodes partielles dans les interfaces ? Permettent-elles, interdisent ou exigent-elles le mot-clé private ?
Dans une méthode par défaut, object.MemberwiseClone () doit-il être accessible?
Enfin, le nom officiel de la fonctionnalité doit-il s'appeler RuntimeFeature.DefaultInterfaceImplementation ? La réponse: "Le LDM ne se soucie pas de son nom."