K-ballo changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
khuck has quit [Read error: Connection reset by peer]
khuck_ has joined #ste||ar
surbhi has quit [Read error: Connection reset by peer]
surbhi has joined #ste||ar
hkaiser has quit [Quit: bye]
diehlpk_work_ has quit [Remote host closed the connection]
shahrzad has quit [Quit: Leaving]
akheir has quit [Quit: Leaving]
bita_ has quit [Ping timeout: 260 seconds]
hkaiser has joined #ste||ar
diehlpk_work has joined #ste||ar
akheir has joined #ste||ar
<hkaiser>
ms[m], rori: meeting
<rori>
isn't it at 4pm usually? ^^'
<rori>
oh yeah we change hours
<K-ballo>
gotta love DST
<rori>
makes sense
<hkaiser>
lol, you have changed timezones, we don't
<K-ballo>
it does have the obvious lifetime extension.. are you thinking of a non obvious one?
<K-ballo>
auto&& x = make_temp(); // life-extended
<K-ballo>
for (auto&& e : make_temp()) // life-extended
<K-ballo>
auto&& x = make_temp().and_then_some(); // not life-extended
<zao>
It's the latter one that's surprising if you're used to function calls and other languages.
<K-ballo>
sure, but if you find it surprising it's surprising everywhere.. range-for isn't special
<zao>
I'd say that a lot of people are not familiar with lifetime extension at all.
<zao>
Nor familiar with the desugar of range-for.
<K-ballo>
I can certainly agree with that
<K-ballo>
I don't buy the "obviousness" wrt range-for
<zao>
While I'd reckon that it's somewhat "known" for function calls that no intermediary expires until the next sequence point or whatever.
<K-ballo>
until the semicolon (kinda, not quite, but ignorable in real life)
<zao>
As for "obvious", well... read "I assumed".
<K-ballo>
if (auto && x = make_temp().and_then_some()) // obvious?
<zao>
Maybe.
<zao>
TBH, before seeing Josuttis' post I hadn't thought about lifetimes at all around range-for, assuming that it would Do The Right Thing.
<K-ballo>
it does the right thing :)
<K-ballo>
i would not be against "fixing" lifetime extension everwhere, or at least for control statements, or even only for range-for if that's the only one we can manage to pass
<K-ballo>
I don't see what's special about range-for that one would expect extra lifetime extensions that don't apply to traditional for
bita_ has joined #ste||ar
<zao>
I may be biased coming from Rust where it Just Works.
<zao>
I have to admit that I first misunderstood the issue to apply to all temporaries, not just chained ones.
<gnikunj[m]>
za myo my friend uses Rust for everything. His reviews are very positive and he insists me to shift to rust :D
<K-ballo>
it'd be great if it just worked for all control statements (if not everywhere)
<zao>
gnikunj[m]: I'm moving back to C++ in anticipation of maybe changing jobs and brushing up on my knowledge.
<zao>
Did you people know that C++14/17/20 happened while I looked away? :D
<K-ballo>
I seem to remember we discussed "everywhere" back whit the `lifetimebound` proposal, and it was a no go
<K-ballo>
*with
<gnikunj[m]>
zao all the best for you job hunt!
<gnikunj[m]>
May you find a company that uses C++ right :D
<zao>
The game studio I'm considering are on C++17 atm and uses the SC++L and some Boost at least.
<zao>
So they're not pants-on-head reinvent-everything.
<K-ballo>
gnikunj[m]: I don't think there are any :/
<gonidelis[m]>
zao: saw that tweet too
<gonidelis[m]>
what's lifetime ectention
<gonidelis[m]>
?
<gonidelis[m]>
is it like for how long does the initilizer exist?
<K-ballo>
it's an awkward language mechanism that "promotes" a temporary into a real variable when bound to a reference
<K-ballo>
where `X&& var = make_temp();` is effectively doing `X var = make_temp();`
<zao>
Historical uses have been for generic code which may not know if they are dealing with value or reference returns.
<K-ballo>
most historical use was scope guards!
<gonidelis[m]>
hey! K-ballo why would a language want that? for the temps to be forwareded as values (without the developer wanting to)?
<K-ballo>
uh no, I was trying to keep it short.. the real transformation would be
<K-ballo>
`X __var{make_temp()}; X&& var = _var;`
<K-ballo>
without lifetime extension, the temporary would die at the ;
<gonidelis[m]>
ok... why would someone want to keep `__var` ?
<K-ballo>
why would someone want to introduce a reference to make it point to something that no longer exist?