Re: C++ feature proposal: specialize conversions for type of usage (local, member, parameter, etc.)

2015-10-12 Thread Michael Layzell 
This would probably be implemented for us with the static analysis, and an
attribute MOZ_PARAMETER_ONLY_RESULT. I don't know how hard that would be to
implement, but it looks a lot like the work I'm doing in
https://bugzilla.mozilla.org/show_bug.cgi?id=1191540, so I imagine that
once I figure out how to get that one to work nicely (right now it's
misbehaving due to templates being annoying), this one will fall out pretty
easily.

IIRC another problem you were trying to solve was that casting a
nsCOMPtr which is a reference to a member, to a T* would be illegal,
while a local variable would be legal. Again, I think that could be done by
a MOZ_STACK_THIS attribute or similar, which would reject calls unless the
implicit this parameter was an l-value reference to an automatic variable
on the stack.

On Sun, Oct 11, 2015 at 7:09 AM, Aryeh Gregor  wrote:

> In bug 1193762, there's been work on eliminating the implicit
> conversion from nsCOMPtr to T*, at least for rvalues, to avoid the
> safety problem discussed there.  The problem is that then you can't
> pass an nsCOMPtr&& to a function that wants a T*, even though this
> is perfectly safe: the lifetime of the temporary is guaranteed to
> outlast the function call.  The only solution hitherto devised other
> than requiring lots of .get() is to invent a new type for refcounted
> function parameters, which is awkward.
>
> A new language feature could be used to solve this: allow conversion
> operators to behave differently based on how the variable is declared.
> For instance, it might convert differently if the source or
> destination is a local variable, global/static variable, member
> variable, or function parameter.  This would allow our problem to be
> easily solved by defining something in nsCOMPtr like:
>
>   operator T* [[parameter]]()&&;
>
> while leaving the operator deleted for non-parameters.
>
> If this can be declared on any method, or perhaps on the class itself,
> it could also be used to enforce nsCOMPtr not being used as a global
> or static variable.  Are there other places where this would be
> useful?  I don't know if this makes sense to propose as a language
> feature, but I thought it would be worth bringing up in case anyone
> has more compelling use-cases.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

C++ feature proposal: specialize conversions for type of usage (local, member, parameter, etc.)

2015-10-11 Thread Aryeh Gregor 
In bug 1193762, there's been work on eliminating the implicit
conversion from nsCOMPtr to T*, at least for rvalues, to avoid the
safety problem discussed there.  The problem is that then you can't
pass an nsCOMPtr&& to a function that wants a T*, even though this
is perfectly safe: the lifetime of the temporary is guaranteed to
outlast the function call.  The only solution hitherto devised other
than requiring lots of .get() is to invent a new type for refcounted
function parameters, which is awkward.

A new language feature could be used to solve this: allow conversion
operators to behave differently based on how the variable is declared.
For instance, it might convert differently if the source or
destination is a local variable, global/static variable, member
variable, or function parameter.  This would allow our problem to be
easily solved by defining something in nsCOMPtr like:

  operator T* [[parameter]]()&&;

while leaving the operator deleted for non-parameters.

If this can be declared on any method, or perhaps on the class itself,
it could also be used to enforce nsCOMPtr not being used as a global
or static variable.  Are there other places where this would be
useful?  I don't know if this makes sense to propose as a language
feature, but I thought it would be worth bringing up in case anyone
has more compelling use-cases.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: C++ feature proposal: specialize conversions for type of usage (local, member, parameter, etc.)

2015-10-11 Thread Aryeh Gregor 
On Sun, Oct 11, 2015 at 2:09 PM, Aryeh Gregor  wrote:
> A new language feature could be used to solve this: allow conversion
> operators to behave differently based on how the variable is declared.
> For instance, it might convert differently if the source or
> destination is a local variable, global/static variable, member
> variable, or function parameter.  This would allow our problem to be
> easily solved by defining something in nsCOMPtr like:
>
>   operator T* [[parameter]]()&&;
>
> while leaving the operator deleted for non-parameters.

Actually, you could perhaps do even better than that.  Use nsCOMPtr
for refcounted parameters instead of T*, and then delete the T*
constructor for [[parameter]] nsCOMPtr, and have the constructor
and destructor for nsCOMPtr parameters not do addref/release.  Then
you have the effect of bug 1194195 without having to introduce a new
type.  nsCOMPtr(/RefPtr) would be the type to use anywhere you want to
require a strong reference, and it would magically sort out the
addrefs/releases for you.  (Although I know a lot of people don't like
such magic either, so this isn't strictly superior.  But the option
would be available.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: C++ feature proposal: specialize conversions for type of usage (local, member, parameter, etc.)

2015-10-11 Thread Eric Rescorla 
Note: I'm not taking a position on the language feature, just between
your two designs.

-Ekr


On Sun, Oct 11, 2015 at 5:34 AM, Eric Rescorla  wrote:

>
> On Sun, Oct 11, 2015 at 4:28 AM, Aryeh Gregor  wrote:
>
>> On Sun, Oct 11, 2015 at 2:09 PM, Aryeh Gregor  wrote:
>> > A new language feature could be used to solve this: allow conversion
>> > operators to behave differently based on how the variable is declared.
>> > For instance, it might convert differently if the source or
>> > destination is a local variable, global/static variable, member
>> > variable, or function parameter.  This would allow our problem to be
>> > easily solved by defining something in nsCOMPtr like:
>> >
>> >   operator T* [[parameter]]()&&;
>> >
>> > while leaving the operator deleted for non-parameters.
>>
>> Actually, you could perhaps do even better than that.  Use nsCOMPtr
>> for refcounted parameters instead of T*, and then delete the T*
>> constructor for [[parameter]] nsCOMPtr, and have the constructor
>> and destructor for nsCOMPtr parameters not do addref/release.  Then
>> you have the effect of bug 1194195 without having to introduce a new
>> type.  nsCOMPtr(/RefPtr) would be the type to use anywhere you want to
>> require a strong reference, and it would magically sort out the
>> addrefs/releases for you.  (Although I know a lot of people don't like
>> such magic either, so this isn't strictly superior.  But the option
>> would be available.)
>
>
> This seems far superior because it encourages people not to unbox
> pointers which seems like a good thing all other things being equal.
> (I'd actually go further, and say it's a good thing in general, but not
> everyone seems to agree)
>
> -Ekr
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: C++ feature proposal: specialize conversions for type of usage (local, member, parameter, etc.)

2015-10-11 Thread Eric Rescorla 
On Sun, Oct 11, 2015 at 4:28 AM, Aryeh Gregor  wrote:

> On Sun, Oct 11, 2015 at 2:09 PM, Aryeh Gregor  wrote:
> > A new language feature could be used to solve this: allow conversion
> > operators to behave differently based on how the variable is declared.
> > For instance, it might convert differently if the source or
> > destination is a local variable, global/static variable, member
> > variable, or function parameter.  This would allow our problem to be
> > easily solved by defining something in nsCOMPtr like:
> >
> >   operator T* [[parameter]]()&&;
> >
> > while leaving the operator deleted for non-parameters.
>
> Actually, you could perhaps do even better than that.  Use nsCOMPtr
> for refcounted parameters instead of T*, and then delete the T*
> constructor for [[parameter]] nsCOMPtr, and have the constructor
> and destructor for nsCOMPtr parameters not do addref/release.  Then
> you have the effect of bug 1194195 without having to introduce a new
> type.  nsCOMPtr(/RefPtr) would be the type to use anywhere you want to
> require a strong reference, and it would magically sort out the
> addrefs/releases for you.  (Although I know a lot of people don't like
> such magic either, so this isn't strictly superior.  But the option
> would be available.)


This seems far superior because it encourages people not to unbox
pointers which seems like a good thing all other things being equal.
(I'd actually go further, and say it's a good thing in general, but not
everyone seems to agree)

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform