Comportement incohérent de la fonction map avec une valeur vide dans Supply et plain Array ?

Question

Récemment, j'ai appris le cadre Combine de Swift.

Selon les termes d'Apple, "le cadre Combine fournit une approche déclarative de la manière dont votre application traite les événements. Plutôt que d'implémenter potentiellement plusieurs rappels de délégués ou fermetures de gestionnaires d'achèvement, vous pouvez créer une seule chaîne de traitement pour une source d'événement donnée. Chaque partie de la chaîne est un opérateur Combine qui effectue une action distincte sur les éléments reçus de l'étape précédente."

Dans Combine, il existe une fonction appelée compactMap qui peut filtrer les valeurs nulles :

import Combine

let strings = ["a", "1.24", "3", "def", "45", "0.23"].publisher

strings
  .compactMap { Float($0) }
  .sink(receiveValue: {
    print($0)
  })
  .store(in: &subscriptions)
)

Je réécris le code ci-dessus dans Raku comme suit :

my @strings = ["a", "1.24", "3", "def", "45", "0.23"];
my Supply $supply = Supply.from-list(@strings);
my Supply $compact = $supply.map(-> $value {
  try { Num($value) }
  if $! { Empty } else { Num($value) }
 }); # .grep(Num);

$compact.tap(
    &say,
    done => { say 'finished' },
    quit => { say 'done'     }
);

# ()   <--
# 1.24
# 3
# ()   <--
# 45
# 0.23

Mais il produit également deux parenthèses vides. Lorsque l'on utilise map sur un simple tableau au lieu d'un Supply, la map avec la valeur Empty est filtrée :

my @strings = ["a", "1.24", "3", "def", "45", "0.23"];

my @compacted = @strings.map(-> $value {
    try { Num($value) }
    if $! { Empty } else { Num($value) }
});

.say for @compacted;

# 1.24
# 3
# 45
# 0.23

Est-ce que le comportement de map fonction avec Vide valeur dans Supply et simple Array incohérent ?

Answer 1

Pourquoi ne pas le faire comme ça...

my @strings = ["a", "1.24", "3", "def", "45", "0.23"];

my $supply = Supply.from-list(@strings);
my $compact = $supply.grep(*.Num.so);
$compact.tap(&say);

# 1.24
# 3
# 45
# 0.23

Je suis d'accord qu'il semble y avoir une petite divergence (liée à la gestion des défaillances) par rapport à grep normal (pas de .so nécessaire)...

say @strings.grep(*.Num);
#(1.24 3 45 0.23)