Więc natknąłem się na ten (IMHO) bardzo fajny pomysł użycia złożonej struktury wartości zwracanej i wyjątku -Expected<T>. Przezwycięża wiele wad tradycyjnych metod obsługi błędów (wyjątki, kody błędów).

ZobaczPrzemówienie Andrei Alexandrescu (Systematic Error Handling in C ++) ijego slajdy.

Wyjątki i kody błędów mają zasadniczo takie same scenariusze użycia z funkcjami, które zwracają coś i te, które nie.Expected<T>z drugiej strony wydaje się, że jest on ukierunkowany tylko na funkcje zwracające wartości.

Moje pytania to:

Czy któryś z was próbowałExpected<T> w praktyce?Jak zastosowałbyś ten idiom do funkcji, które nie zwracają niczego (czyli funkcji pustych)?

Aktualizacja:

Myślę, że powinienem wyjaśnić moje pytanie. TheExpected<void> specjalizacja ma sens, ale bardziej interesuje mnie, w jaki sposób zostanie ona użyta - spójny idiom użytkowania. Sama implementacja jest drugorzędna (i łatwa).

Na przykład Alexandrescu podaje ten przykład (nieco zmieniony):

string s = readline();
auto x = parseInt(s).get(); // throw on error
auto y = parseInt(s); // won’t throw
if (!y.valid()) {
    // ...
}

Ten kod jest „czysty” w taki sposób, że po prostu płynie naturalnie. Potrzebujemy wartości - dostajemy ją. Jednak zexpected<void> należałoby przechwycić zwróconą zmienną i wykonać na niej jakąś operację (np.throwIfError() lub coś), co nie jest tak eleganckie. I oczywiście.get() nie ma sensu z pustką.

Jak wyglądałby twój kod, powiedzmy, gdybyś miał inną funkcjętoUpper(s), który modyfikuje łańcuch w miejscu i nie ma wartości zwracanej?