deferring destruction

[Francisco Lopes]

It has been some years this idea floats in my mind as a nice feature, so I'd like
to ask you guys whether you also feel it would be helpful as I think so, it's my first proposal sketch here.

I'd like to suggest a new keyword, defer, whose main purpose is to extend
the lifetime of a temporary following it, to the enclosing scope.

Which would help on situations like this

#include <memory>
#include <iostream>

int main() {
    std::shared_ptr<void> at_exit_1(nullptr, [](...){ std::cout << 4; });
    std::cout << 1;

    std::shared_ptr<void> at_exit_2(nullptr, [](...){ std::cout << 3; });
    std::cout << 2;
}

which could be rewritten like:

#include <memory>
#include <iostream>

int main() {
    defer std::shared_ptr<void>(nullptr, [](...){ std::cout << 4; });
    std::cout << 1;

    defer std::shared_ptr<void>(nullptr, [](...){ std::cout << 3; });
    std::cout << 2;
}

without having to care for naming without necessity.

I know such kind of situation happen not only when using that kind of at_exit
trick, but also, this is a feature that couples perfectly to std::lock_guard
or any kind of guard for that matter.

This would also have a strong connection with the scope_exit & unique_resource
proposal.

The keyword is inspired in the defer keyword from the Go programming language.

Actually, I just happened to come here after reviewing some questions on StackOverflow
where I have had participation:

- http://stackoverflow.com/questions/33050620

Regards,
Francisco Lopes

[Francisco Lopes]

Ah, I just realized... new keyword yeah, it's problematic to add. But I care more
for the feature, not how it enters, so let's assume that requiring a new keyword
is not a requirement in the proposal.

[Francisco Lopes]

It would also be like having the hability of declaring anonymous variables.
It could be possible to obtain the same as defer if it was possible to have
a special variable name placeholder that in truth woudn't name anything, it could
be auto?!

#include <memory>
#include <iostream>

int main() {

    std::shared_ptr<void> auto(nullptr, [](...){ std::cout << 4; });
    std::cout << 1;

    std::shared_ptr<void> auto(nullptr, [](...){ std::cout << 3; });
    std::cout << 2;
}

Anyway, I'd not like to disperse, just focus on the functionality.

[Tony V E]

I've been considering a feature where we could use (and reuse) _ as an anonymous variable name. 

Foo _ = 10; //allowed today

_.member(); // ok

Bar _ = 5; // new - anonymous variable‎ (both _ in scope)

_.func(); // compile failure‎ - ambiguous _

Basically allow one or more variables named _. 

If you have just one, then everything works as today (backwards compatible). 

Once you have more than one _ variable, they all become anonymous.

Sent from my BlackBerry portable Babbage Device

From: Francisco Lopes Sent: Saturday, July 9, 2016 6:26 PM To: ISO C++ Standard - Future Proposals Reply To: std-pr...@isocpp.org Subject: [std-proposals] Re: deferring destruction

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c7f9426b-47db-4760-848d-19354dd5fa82%40isocpp.org.

[Francisco Lopes]

I've considered (but not commented) about using _ too. It's what I employ
in the referred stackoverflow link.

You approach is interesting, another one that's also backwards compatible
is to make _ refer to the last object, overriding the previous one without
destructing it on overriding.

[Francisco Lopes]

heh, ok. Using _ made me also connect it with the destructuring/multiple-return proposal.

[Francisco Lopes]

Meaning, if we ever get destructuring with a placeholder (afaik it has been explicitly excluded from
current proposal) wouldn't it actually touch this same subject?

[Francisco Lopes]

We may accept the subject changed to "Anonymous Variables" by now.

[Francisco Lopes]

By initially searching deferred destruction I coudn't find anything, but anonymous variables give the following
old topics:

- https://groups.google.com/a/isocpp.org/d/msg/std-proposals/GJ-3seXeIl4/bS-O_9rnZosJ
- https://groups.google.com/a/isocpp.org/d/msg/std-proposals/BfAtczj81Kg/pga0JJ2JijwJ

[Francisco Lopes]

To sum the arguments in favor of the proposal for today, compared to the fewer usecases presented years back:

Having anonymous variables would:

- Improve ergonomics for multiple return and destructuring.
- Improve ergonomics for any kind of scope guards.
- Improve ergonomics for scope_exit usage.

[Arthur O'Dwyer]

On Saturday, July 9, 2016 at 3:01:54 PM UTC-7, Francisco Lopes wrote:

It has been some years this idea floats in my mind as a nice feature, so I'd like
to ask you guys whether you also feel it would be helpful as I think so, it's my first proposal sketch here.

I'd like to suggest a new keyword, defer, whose main purpose is to extend
the lifetime of a temporary following it, to the enclosing scope.

[...]

The keyword is inspired in the defer keyword from the Go programming language.

Actually, I just happened to come here after reviewing some questions on StackOverflow
where I have had participation:

- http://stackoverflow.com/questions/33050620

I've just posted an answer that I think will satisfy your craving for Go's defer statement in C++; please take a look.

http://stackoverflow.com/a/38289141/1424877

In general, the C++ standard will never have anything like defer, because C++ has something better and safer: destructors. When you have proper RAII, you don't need a mechanism for deferring arbitrary code; the only reason to defer arbitrary code is for hacks (and I say that having written a lot of such hacks myself). Standardizing such a mechanism would be sending the wrong message; the standard should be encouraging and standardizing things that allow people to write better and more maintainable code, not worse code.

That said, if you need something like it in your codebase, the complete source code to Auto() is only 16 lines long. I provided it cut-and-pasteable in that StackOverflow answer.

HTH,

–Arthur

[Francisco Lopes]

Thanks for your answer Arthur.

I advice you to take a look in my previous message in the topic, anonymous
variables woudn't benefit only that usecase.

Personally, I'm not interested in carrying such kind of code around anywhere
I work, just like I don't like to have to carry any bit that has been standardized,
that's what the standardization process exists for. Standardize useful tools that
otherwise are present in many codebases implemented by diverse manners.
I've seen scope_exit etc present in many well known code bases.

scope_exit and unique_resource thread has many argument battles regarding that,
I myself was present in there. My point of view about this is that there's
no point going forward on this. There are non-definite arguments from
both sides, and the choice boils down to taste, if we go forward it will
be just a religious battle.

I take your point but I really don't wish to go back to the scope_exit and
unique_resource discussion. As said before, anonymous variables could
help not only this but also ergonomics for:

- multiple return and destructuring.
- any kind of scope guards.
- scope_exit usage.

And I think the usecases will keep growing.

[Francisco Lopes]

I've opted to move the topic for better focus to:

- https://groups.google.com/a/isocpp.org/d/msg/std-proposals/OKUpODP9-7w/oQq-asoYCgAJ

Consider this one closed, thanks.

[FrankHB1989]

I don't think the phrase "anonymous variable" well-formed technically. Traditionally, a variable always has at least one name in some scope. It has not been changed in C++, and I don't think it needed to be changed. Perhaps "unnamed variable" would be better.
BTW, union can be anonymous; namespaces are not allowed to be specified anonymous by users; the global namespace is "anonymous".

在 2016年7月10日星期日 UTC+8上午8:35:09，Francisco Lopes写道：