--001a1147b01ca442fb053b41fb03
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 29, 2016 at 11:04 AM Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2016-08-24 14:51, nicolas.capens@gmail.com wrote:
> > I'd like to propose a new kind of destructor that gets called after a
> local
> > object's last use, instead of at the end of its scope.
> > [...]
>
> General follow-up... I'm not sure I'm in favor of this proposal in
> general, but I don't see it as feasible to make it a type property. You
> are almost inevitably going to have cases where the feature needs to be
> controlled on a per-variable basis, and having to produce duplicate
> types (and convert between them!) is not practical, not to mention that
> you may want to use it on types outside your control. (You mention
> matrices a lot; well, what if I'm using Eigen matrices and want this?)
>

Although you're not alone in the opinion that this would have to be
controlled on a per-variable basis, I still haven't seen any sound
arguments for that. It seems too mix-and-matchy to me, putting a
significant burden on both the writer and the reader of the code to make
sure it's working as intended. It seems very likely to me that a portion of
code is going to use a set of variables of the same type that can be
eagerly destructed and which avoids the pitfalls, or you don't really care
about it for that and just want the legacy lazy destruction and the
assurance that you can take references to internal data the usual way.

Types are either designed to behave self-contained or not. So it makes more
sense to me to link eager destruction to the type.

I do understand the desire to use eager destruction on types outside of
your control, but let's be careful not to prioritize short term benefits
over long term issues. All classes that would benefit from eager
destruction, eventually will use it, and this might involve some careful
redesigning by the authors. Forcefully overriding that may cause
significant problems in the longer term.


> And then it occurred to me... we have the `register` keyword just
> sitting there. And you keep referring to register allocation of
> scalars... it seems that the old meaning of `register` is almost exactly
> what you want.
>

That's indeed a pretty good option for a recycled keyword for this. :-) It
didn't quite have the same meaning, but does convey the idea of
self-containedness or wanting a variable to be more aggressively optimized.
It was also always merely a hint, and in legacy code it's mostly used on
scalars so there is little risk of breaking it.


> It may also make sense to make it UB to take and retain a reference to
> any `register` variable, including references to members of the same. If
> we *really* wanted to be safe, we could make `register` a qualifier
> (i.e. allow its use on function parameters) and make it *ill-formed* to
> take a (non-`register`) reference to a `register` variable. This way,
> you could still pass such a variable by reference to a function, but the
> function would not be allowed to retain that reference. (This obviously
> implies that no global variable may be `register` qualified, and the
> presence of a `register` qualified member implies that the containing
> object may only be used as a `register` variable itself.) This would
> require much more extensive API modification for the feature to be
> widely used, but the added safety might be worth it.
>

Yes, I think this is a really good idea that would avoid many if not all of
the pitfalls with taking references to eagerly destructed types/variables!


> In fact, I can see some other potential (though probably breaking) uses
> for such a feature. For example, std::string::data() could return `char*
> register` instead of plain `char*` to indicate to callers that they may
> not retain the returned pointer. (Maybe this could be a feature for
> STL2...)
>
> --
> Matthew
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/IUxA4cx8yHc/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/57C44F09.4010901%40gmail.com
> .
>

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAE7XuEX-4cBSO4Vzai6N_GqN6Vj%2B3313prrhENVZQOeVpfpYqA%40mail.gmail.com.

--001a1147b01ca442fb053b41fb03
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 29=
, 2016 at 11:04 AM Matthew Woehlke &lt;<a href=3D"mailto:mwoehlke.floss@gma=
il.com">mwoehlke.floss@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On 2016-08-24 14:51, <a href=3D"mailto:nicolas.capens@gmail.c=
om" target=3D"_blank">nicolas.capens@gmail.com</a> wrote:<br>
&gt; I&#39;d like to propose a new kind of destructor that gets called afte=
r a local<br>
&gt; object&#39;s last use, instead of at the end of its scope.<br>
&gt; [...]<br>
<br>
General follow-up... I&#39;m not sure I&#39;m in favor of this proposal in<=
br>
general, but I don&#39;t see it as feasible to make it a type property. You=
<br>
are almost inevitably going to have cases where the feature needs to be<br>
controlled on a per-variable basis, and having to produce duplicate<br>
types (and convert between them!) is not practical, not to mention that<br>
you may want to use it on types outside your control. (You mention<br>
matrices a lot; well, what if I&#39;m using Eigen matrices and want this?)<=
br></blockquote><div><br></div><div>Although you&#39;re not alone in the op=
inion that this would have to be controlled on a per-variable basis, I stil=
l haven&#39;t seen any sound arguments for that. It seems too mix-and-match=
y to me, putting a significant burden on both the writer and the reader of =
the code to make sure it&#39;s working as intended. It seems very likely to=
 me that a portion of code is going to use a set of variables of the same t=
ype that can be eagerly destructed and which avoids the pitfalls, or you do=
n&#39;t really care about it for that and just want the legacy lazy destruc=
tion and the assurance that you can take references to internal data the us=
ual way.</div><div><br></div><div>Types are either designed to behave self-=
contained or not. So it makes more sense to me to link eager destruction to=
 the type.</div><div><br></div><div>I do understand the desire to use eager=
 destruction on types outside of your control, but let&#39;s be careful not=
 to prioritize short term benefits over long term issues. All classes that =
would benefit from eager destruction, eventually will use it, and this migh=
t involve some careful redesigning by the authors. Forcefully overriding th=
at may cause significant problems in the longer term.</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
And then it occurred to me... we have the `register` keyword just<br>
sitting there. And you keep referring to register allocation of<br>
scalars... it seems that the old meaning of `register` is almost exactly<br=
>
what you want.<br></blockquote><div><br></div><div>That&#39;s indeed a pret=
ty good option for a recycled keyword for this. :-) It didn&#39;t quite hav=
e the same meaning, but does convey the idea of self-containedness or wanti=
ng a variable to be more aggressively optimized. It was also always merely =
a hint, and in legacy code it&#39;s mostly used on scalars so there is litt=
le risk of breaking it.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
It may also make sense to make it UB to take and retain a reference to<br>
any `register` variable, including references to members of the same. If<br=
>
we *really* wanted to be safe, we could make `register` a qualifier<br>
(i.e. allow its use on function parameters) and make it *ill-formed* to<br>
take a (non-`register`) reference to a `register` variable. This way,<br>
you could still pass such a variable by reference to a function, but the<br=
>
function would not be allowed to retain that reference. (This obviously<br>
implies that no global variable may be `register` qualified, and the<br>
presence of a `register` qualified member implies that the containing<br>
object may only be used as a `register` variable itself.) This would<br>
require much more extensive API modification for the feature to be<br>
widely used, but the added safety might be worth it.<br></blockquote><div><=
br></div><div>Yes, I think this is a really good idea that would avoid many=
 if not all of the pitfalls with taking references to eagerly destructed ty=
pes/variables!</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In fact, I can see some other potential (though probably breaking) uses<br>
for such a feature. For example, std::string::data() could return `char*<br=
>
register` instead of plain `char*` to indicate to callers that they may<br>
not retain the returned pointer. (Maybe this could be a feature for STL2...=
)<br>
<br>
--<br>
Matthew<br>
<br>
--<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/IUxA4cx8yHc/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/IUxA4cx8yHc/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/57C44F09.4010901%40gmail.com" rel=3D"=
noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgi=
d/std-proposals/57C44F09.4010901%40gmail.com</a>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAE7XuEX-4cBSO4Vzai6N_GqN6Vj%2B3313pr=
rhENVZQOeVpfpYqA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAE7XuEX-4cBSO4=
Vzai6N_GqN6Vj%2B3313prrhENVZQOeVpfpYqA%40mail.gmail.com</a>.<br />

--001a1147b01ca442fb053b41fb03--

.