Date: Mon, 14 Sep 2020 15:06:12 +0200
On Sun, 13 Sep 2020 at 11:37, Dvir Yitzchaki via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
> On Sun, 13 Sep 2020 at 11:49, Jorg Brown via Std-Proposals <
> std-proposals_at_[hidden]> 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] <https://wg21.link/p0798r4> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
std-proposals_at_[hidden]> wrote:
>
>
> On Sun, 13 Sep 2020 at 11:49, Jorg Brown via Std-Proposals <
> std-proposals_at_[hidden]> 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] <https://wg21.link/p0798r4> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
-- Richard Hodges hodges.r_at_[hidden] office: +442032898513 home: +376841522 mobile: +376380212
Received on 2020-09-14 08:06:26