On Sun, 13 Sep 2020 at 11:37, Dvir Yitzchaki via Std-Proposals <std-proposals@lists.isocpp.org> wrote:


On Sun, 13 Sep 2020 at 11:49, Jorg Brown via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

OK, so if I only use local control structures, and eschew goto and return, then how do I write the typical multiple-error-return flow, without ending up with code that is increasingly indented, right up until the end?  What's the right way, according to your model, of writing:

std::optional<std::string> FindUsersCity(bool non_default) {
     std::optional<std::string> city = std::nullopt;
     std::optional<ContactsServer> contacts = GetOrOpenContactsServerConnection();
     if (contacts) {
          std::optional<UserId> uid = contacts->GetUserId();
          if (uid) {
               std::optional<GeoServer> geo = GetOrOpenGeoServerConnection();
               if (geo) {
                    std::optional<Location> uloc = geo->GetLocation(*uid);
                    if (uloc) {
                         city = uloc->GetCityName();
                    }
               }
          }
     }
     return city;
} 

with [P0798] it can be something like:

std::optional<std::string> FindUsersCity(bool non_default) {
  return GetOrOpenContactsServerConnection()
      .transform([](auto&& contacts) { return contacts->GetUserId(); })
      .and_then([](auto&& uid) {
        return GetOrOpenGeoServerConnection().transform(
            [&uid](auto&& geo) { return geo->GetLocation(*uid); });
      })
      .transform([](auto&& uloc) { return uloc->GetCityName(); });
}

Standardisation or not, I will never allow anyone who works for me to commit this kind of code.
It represents abstraction for its own sake and makes code impossible to debug or even read.
The first question that springs to mind is "where do I place the breakpoint so I can see the current state of this algorithm?"
The alternatives:
expression statements,
lambdas,
coroutines
do not suffer from this problem as they present code as an easily-reasoned-about sequence of statements that have clear cause and effect.

Therefore in my mind, p0798 is not an answer to this proposal.

 
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


--
Richard Hodges
office: +442032898513
home: +376841522
mobile: +376380212