Re: Intent to ship: NetworkInformation

[Boris Zbarsky]

On 12/22/16 10:31 PM, mcace...@mozilla.com wrote:

(e.g., Boris' somewhat esoteric network setup)


Just to check, are you talking about my typical setup for accessing the 
internet (which is totally non-esoteric laptop talks to wifi talks to 
ISP) or the "privacy leak" cases?


> Most people have wifi at home

Right, that is _precisely_ my setup.  (And claiming that it's a 600Mbit 
or 6933.3 MBit connection as this API spec would require us to do is 
nonsense on a pie plate, but maybe we're not talking about that column 
of the nice table anymore?)



which is somewhat unmetered - and access to mobile data, which often costs more 
(but not always true).


OK, sure, so we want the "does the user have to pay for this?" boolean.

The API sure goes out of its way to hide that information (e.g. you have 
to know which of those transport types are typically metered or not) 
_and_ make it not forward compatible (new types being added?  business 
models for existing types changing?).



The API, though ".type", allows the user and app to have a conversation about that: 
"you want me to download stuff over mobile? Its might cost ya, but if you are ok with 
it...".


If this is the use case we're trying to address, a "mayBeMetered" 
boolean is the way to go, I believe.



Certainly things could be improved - but again, the API just addresses the 
basic use cases


It addresses them _really_ badly, in my opinion.


However, if we do get better native integration in the platform (particularly 
as it relates to multimedia assets), then this will be needed


Or a better API that provides the information people actually care 
about?  Yes, I realize there is a bit of an uphill battle to get people 
to actually adopt the better API.  I think in this case, this API is 
sufficiently horrible that it's worth it...


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

Re: Intent to implement: HTML5 element

[Boris Zbarsky]

On 12/22/16 10:03 PM, Martin Thomson wrote:

On Fri, Dec 23, 2016 at 7:14 AM, Boris Zbarsky  wrote:

Note that I expect that this spec was written before Promise was a thing.
The setup where we return a value in an attribute of the element (!) is
pretty bizarre...


Is this irredeemable?


Probably not.


I mean, the attribute is probably a lost cause


Why?  Is there significant usage, or at least wide implementation, of 
that part of the API already?  The original intent said that only Chrome 
is shipping this.



but a void function can usually be safely transformed into a
Promise-bearing one.


Indeed.

-Boris

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

Re: Intent to ship: NetworkInformation

[mcaceres]

On Wednesday, December 21, 2016 at 12:51:10 AM UTC+11, Eric Rescorla wrote:
> I'm not really following this argument. Usually when a document has been
> floating
> around a long time but clearly has basic design issues and can't get
> consensus,
> even when a major vendor has implemented it, that's a sign that it
> *shouldn't*
> be standardized until those issues are resolved. That's not standards
> fatigue,
> it's the process working as designed.

The API addresses the use cases, but people here see those use cases as too 
basic because they don't represent average users (e.g., Boris' somewhat 
esoteric network setup). Most people have wifi at home, which is somewhat 
unmetered - and access to mobile data, which often costs more (but not always 
true). 

The API, though ".type", allows the user and app to have a conversation about 
that: "you want me to download stuff over mobile? Its might cost ya, but if you 
are ok with it...".
 
> None of this seems to add up to a strong argument that this functionality
> should be in Firefox

Certainly things could be improved - but again, the API just addresses the 
basic use cases (i.e., the 80% case - that gives us parity with native apps). 
The web still can't do most of the things this API is actually needed for 
(e.g., enabling apps like audio books, magazine subscriptions, etc.) so it's 
not too much of a big deal right now that it's not available. 

However, if we do get better native integration in the platform (particularly 
as it relates to multimedia assets), then this will be needed (or people will 
just use Chrome, as it will provide better control over downloads on mobile - 
which will be sad).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

[Martin Thomson]

On Fri, Dec 23, 2016 at 7:14 AM, Boris Zbarsky  wrote:
> Note that I expect that this spec was written before Promise was a thing.
> The setup where we return a value in an attribute of the element (!) is
> pretty bizarre...

Is this irredeemable?  I mean, the attribute is probably a lost cause,
but a void function can usually be safely transformed into a
Promise-bearing one.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

[Tim Nguyen]

Non-modal dialogs should just work fine in a chrome window (the dialog
would just be like a centered absolute positioned div). As for modal
dialogs (eg. dialogs that makes everything else inert), it would depend on
whether the current top-layer implementation works within a chrome window
and I don't think it is the case currently. So, I don't expect modal
dialogs to work within the chrome window (at least not without some extra
platform work). Xidorn might know better though.

As for how modal dialogs *should* behave in a chrome window, I would expect
it to be the same as for web content, i.e. it modal dialogs should make all
UI elements except the current dialog inert.

Tim


On Fri, Dec 23, 2016 at 12:33 AM, Justin Dolske  wrote:

> What's the expected experience if chrome code uses this feature? (In a
> chrome window, interaction with a content window isn't the thing I'm
> wondering about.)
>
> Justin
>
> On Tue, Dec 20, 2016 at 3:56 PM, Tim Nguyen  wrote:
>
>> *Summary*:
>> The *HTML  element* represents a dialog box or other interactive
>> component, such as an inspector or window.
>> It will initially be implemented behind a pref.
>>
>> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=840640
>>
>> *Link to standard*: https://html.spec.whatwg.org/m
>> ultipage/forms.html#the-
>> dialog-element
>> 
>>
>> *Platform coverage*: All
>>
>> *Estimated or target release*: Firefox 54
>>
>> *Preference behind which this will be implemented*:
>> dom.dialog_element.enabled
>>
>> *DevTools bug*: None yet, although I'm not sure how we can make DevTools
>> more useful here ?
>>
>> *Do other browser engines implement this?*
>> Shipped: Chrome (since version 37)
>> Considering: Edge ( http://status.modern.ie/dialogelementformodals )
>>
>> *Tests*:
>> https://github.com/w3c/web-platform-tests/blob/master/
>> html/dom/interfaces.html#L1835
>> https://github.com/w3c/web-platform-tests/tree/master/
>> html/semantics/interactive-elements/the-dialog-element
>> ___
>> 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

Re: Intent to implement: HTML5 element

[Justin Dolske]

What's the expected experience if chrome code uses this feature? (In a
chrome window, interaction with a content window isn't the thing I'm
wondering about.)

Justin

On Tue, Dec 20, 2016 at 3:56 PM, Tim Nguyen  wrote:

> *Summary*:
> The *HTML  element* represents a dialog box or other interactive
> component, such as an inspector or window.
> It will initially be implemented behind a pref.
>
> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=840640
>
> *Link to standard*: https://html.spec.whatwg.org/multipage/forms.html#the-
> dialog-element
>
> *Platform coverage*: All
>
> *Estimated or target release*: Firefox 54
>
> *Preference behind which this will be implemented*:
> dom.dialog_element.enabled
>
> *DevTools bug*: None yet, although I'm not sure how we can make DevTools
> more useful here ?
>
> *Do other browser engines implement this?*
> Shipped: Chrome (since version 37)
> Considering: Edge ( http://status.modern.ie/dialogelementformodals )
>
> *Tests*:
> https://github.com/w3c/web-platform-tests/blob/master/
> html/dom/interfaces.html#L1835
> https://github.com/w3c/web-platform-tests/tree/master/
> html/semantics/interactive-elements/the-dialog-element
> ___
> 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

Re: Async scrollbar dragging enabled on Nightly

[Botond Ballo]

On Mon, Dec 19, 2016 at 2:16 PM, Botond Ballo  wrote:
> Async scrolling (APZ) has been enabled for a new input method,
> scrollbar dragging, on the Nightly branch.

Sorry, I should have mentioned this sooner, but this was backed out
due to a test failure before reaching m-c. So, any issues you might be
seeing with scrollbar dragging on currently m-c are not related to
this :)

I'll send another message when this lands and sticks.

Cheers,
Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

[Boris Zbarsky]

On 12/21/16 4:13 PM, Xidorn Quan wrote:

This is a question for the spec. I guess it theoretically can return a
Promise, though I suspect that there might be some weird corner cases
which is hard to handle.


Note that I expect that this spec was written before Promise was a 
thing.  The setup where we return a value in an attribute of the element 
(!) is pretty bizarre...



Anyway, I don't think dev-platform is the right place for this kind of
spec issues. You can raise an issue to HTML spec to start the discussion
there.


Sure, but it bears on whether we want to ship the spec in its current state.

-Boris

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

Re: Introducing mozilla::Result for better error handling

[Nick Fitzgerald]

FWIW, you can also avoid the
check-for-error-and-early-return-or-else-unwrap dance that is being
"hidden" within MOZ_TRY by using `mozilla::Result::andThen` (and
`mozilla::Result::map`) which are on inbound and will be on m-c soon.

The patch in https://bugzilla.mozilla.org/show_bug.cgi?id=1324829 has
example usage.

On Thu, Dec 22, 2016 at 10:20 AM, Kris Maglione 
wrote:

> On Wed, Dec 21, 2016 at 11:22:24PM -0800, Eric Rahm wrote:
>
>> The key point for me is that we're hiding the return. I'm fine with the
>> more verbose explicitly-return-and-make-it-easier-for-the-reviewer-to-cal
>> l-out-issues
>> form.
>>
>
> I've never been convinced by that argument. Reviewers accept code with
> early return macros should be familiar enough with them that they don't
> make it any harder to spot issues caused by early return. On the flip side,
> explicit early return is a pervasive enough pattern that I think most of us
> tend to just filter it out as noise. But it's noise that makes the
> structure of the code much harder to follow, which makes other errors much
> easier to miss.
>
> And, by the same token, this is part of MFBT, and comes along with a lot
> of other helpers, and a general coding style, that makes it much easier to
> RAII all the things, and to generally do the right thing. In isolation, I
> might worry more about it leading to new early return errors, but in
> context, I think it's clearly a step in the right direction.
>
>
> On Wed, Dec 21, 2016 at 10:59 PM, Kris Maglione 
>> wrote:
>>
>> On Wed, Dec 21, 2016 at 10:53:45PM -0800, Eric Rahm wrote:
>>>
>>> I like the idea of pulling in some Rusty concepts, but I'm concerned
 about
 adding yet another early return macro -- absolutely no arguments on the
 new
 type, just the |MOZ_TRY| macro. In practice these have lead to security
 issues (UAF, etc) and memory leaks in the C++ world (I'm looking at you
 NS_ENSURE). These aren't hypothetical issues, I've run into them both
 working on memshrink and sec issues in Firefox.


>>> We run into the same issues without those macros. The only real
>>> difference
>>> is that when you have to follow every call with:
>>>
>>>  if (NS_WARN_IF(NS_FAILED(rv))) {
>>>return rv;
>>>  }
>>>
>>> It's much easier to lose track of the allocation you did four  calls ago
>>> that's now 20 lines away.
>>>
>>>
>>> On Wed, Dec 21, 2016 at 9:53 AM, Ted Mielczarek 
>>>
 wrote:

 On Wed, Dec 21, 2016, at 12:30 PM, Jason Orendorff wrote:

> > The implicit conversion solves a real problem. Imagine these two
> > operations
> > have two different error types:
> >
> > MOZ_TRY(JS_DoFirstThing()); // JS::Error&
> > MOZ_TRY(mozilla::pkix::DoSecondThing()); // pkix::Error
> >
> > We don't want our error-handling scheme getting in the way of using
> them
> > together. So we need a way of unifying the two error types: a shared
> base
> > class, perhaps, or a variant.
> >
> > Experience with Rust says that MOZ_TRY definitely needs to address
> this
> > problem somehow. C++ implicit conversion is just one way to go; we
> can
> > discuss alternatives in the bug.
>
> The `try` macro in Rust will auto-convert error types that implement
> `Into`, AIUI, but that's not automatic for all error types. I
> haven't
> tried it, but I have seen multiple recommendations for the
> `error_chain`
> crate to make this smoother:
> https://docs.rs/error-chain/0.7.1/error_chain/
>
> It's basically just boilerplate to implement conversions from other
> error types. I wouldn't be surprised if something like that percolates
> into the Rust standard library at some point.
>
> -Ted
> ___
> 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


>>> --
>>> Kris Maglione
>>> Firefox Add-ons Engineer
>>> Mozilla Corporation
>>>
>>> It's always good to take an orthogonal view of something.  It develops
>>> ideas.
>>> --Ken Thompson
>>>
>>>
>>>
> --
> Kris Maglione
> Firefox Add-ons Engineer
> Mozilla Corporation
>
> Life is too important to be taken seriously.
> --Oscar Wilde
>
>
> ___
> 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

Re: Introducing mozilla::Result for better error handling

[Kris Maglione]

On Wed, Dec 21, 2016 at 11:22:24PM -0800, Eric Rahm wrote:

The key point for me is that we're hiding the return. I'm fine with the
more verbose 
explicitly-return-and-make-it-easier-for-the-reviewer-to-call-out-issues
form.


I've never been convinced by that argument. Reviewers accept 
code with early return macros should be familiar enough with 
them that they don't make it any harder to spot issues caused by 
early return. On the flip side, explicit early return is a 
pervasive enough pattern that I think most of us tend to just 
filter it out as noise. But it's noise that makes the structure 
of the code much harder to follow, which makes other errors much 
easier to miss.


And, by the same token, this is part of MFBT, and comes along 
with a lot of other helpers, and a general coding style, that 
makes it much easier to RAII all the things, and to generally do 
the right thing. In isolation, I might worry more about it 
leading to new early return errors, but in context, I think it's 
clearly a step in the right direction.



On Wed, Dec 21, 2016 at 10:59 PM, Kris Maglione 
wrote:


On Wed, Dec 21, 2016 at 10:53:45PM -0800, Eric Rahm wrote:


I like the idea of pulling in some Rusty concepts, but I'm concerned about
adding yet another early return macro -- absolutely no arguments on the
new
type, just the |MOZ_TRY| macro. In practice these have lead to security
issues (UAF, etc) and memory leaks in the C++ world (I'm looking at you
NS_ENSURE). These aren't hypothetical issues, I've run into them both
working on memshrink and sec issues in Firefox.



We run into the same issues without those macros. The only real difference
is that when you have to follow every call with:

 if (NS_WARN_IF(NS_FAILED(rv))) {
   return rv;
 }

It's much easier to lose track of the allocation you did four  calls ago
that's now 20 lines away.


On Wed, Dec 21, 2016 at 9:53 AM, Ted Mielczarek 

wrote:

On Wed, Dec 21, 2016, at 12:30 PM, Jason Orendorff wrote:

> The implicit conversion solves a real problem. Imagine these two
> operations
> have two different error types:
>
> MOZ_TRY(JS_DoFirstThing()); // JS::Error&
> MOZ_TRY(mozilla::pkix::DoSecondThing()); // pkix::Error
>
> We don't want our error-handling scheme getting in the way of using
them
> together. So we need a way of unifying the two error types: a shared
base
> class, perhaps, or a variant.
>
> Experience with Rust says that MOZ_TRY definitely needs to address this
> problem somehow. C++ implicit conversion is just one way to go; we can
> discuss alternatives in the bug.

The `try` macro in Rust will auto-convert error types that implement
`Into`, AIUI, but that's not automatic for all error types. I haven't
tried it, but I have seen multiple recommendations for the `error_chain`
crate to make this smoother:
https://docs.rs/error-chain/0.7.1/error_chain/

It's basically just boilerplate to implement conversions from other
error types. I wouldn't be surprised if something like that percolates
into the Rust standard library at some point.

-Ted
___
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



--
Kris Maglione
Firefox Add-ons Engineer
Mozilla Corporation

It's always good to take an orthogonal view of something.  It develops
ideas.
--Ken Thompson




--
Kris Maglione
Firefox Add-ons Engineer
Mozilla Corporation

Life is too important to be taken seriously.
--Oscar Wilde

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

Re: Introducing mozilla::Result for better error handling

[Bobby Holley]

We've had this debate several times already, culminating in the attempt to
ban NS_ENSURE_* macros. It didn't work.

Subjectively, I think the reasons for the failure were:
(a) We want logging/warnings on exceptional return paths, especially the
ones we don't expect.
(b) We want to check every potential failure and propagate error codes
correctly.
(c) Trying to do (a) and (b) consistently without macros bloats every
function call to 5 lines of boilerplate.

If we do want to rehash the early-return macro discussion, we should do
that separately. As it stands, MOZ_TRY is necessary to give mozilla::Result
feature parity with nsresult. We don't want people to stick with nsresult
just because they like NS_ENSURE_SUCCESS.

bholley

On Wed, Dec 21, 2016 at 11:22 PM, Eric Rahm  wrote:

> The key point for me is that we're hiding the return. I'm fine with the
> more verbose explicitly-return-and-make-it-easier-for-the-reviewer-to-
> call-out-issues
> form. I understand this is going to have differing opinions -- I think
> there's merit to more concise code -- but for the things I look at I much
> prefer an explicit return. It makes both the writer and reviewer think
> about the consequences. If MOZ_TRY just release asserted on error I
> wouldn't have an issue.
>
> On Wed, Dec 21, 2016 at 10:59 PM, Kris Maglione 
> wrote:
>
> > On Wed, Dec 21, 2016 at 10:53:45PM -0800, Eric Rahm wrote:
> >
> >> I like the idea of pulling in some Rusty concepts, but I'm concerned
> about
> >> adding yet another early return macro -- absolutely no arguments on the
> >> new
> >> type, just the |MOZ_TRY| macro. In practice these have lead to security
> >> issues (UAF, etc) and memory leaks in the C++ world (I'm looking at you
> >> NS_ENSURE). These aren't hypothetical issues, I've run into them both
> >> working on memshrink and sec issues in Firefox.
> >>
> >
> > We run into the same issues without those macros. The only real
> difference
> > is that when you have to follow every call with:
> >
> >  if (NS_WARN_IF(NS_FAILED(rv))) {
> >return rv;
> >  }
> >
> > It's much easier to lose track of the allocation you did four  calls ago
> > that's now 20 lines away.
> >
> >
> > On Wed, Dec 21, 2016 at 9:53 AM, Ted Mielczarek 
> >> wrote:
> >>
> >> On Wed, Dec 21, 2016, at 12:30 PM, Jason Orendorff wrote:
> >>> > The implicit conversion solves a real problem. Imagine these two
> >>> > operations
> >>> > have two different error types:
> >>> >
> >>> > MOZ_TRY(JS_DoFirstThing()); // JS::Error&
> >>> > MOZ_TRY(mozilla::pkix::DoSecondThing()); // pkix::Error
> >>> >
> >>> > We don't want our error-handling scheme getting in the way of using
> >>> them
> >>> > together. So we need a way of unifying the two error types: a shared
> >>> base
> >>> > class, perhaps, or a variant.
> >>> >
> >>> > Experience with Rust says that MOZ_TRY definitely needs to address
> this
> >>> > problem somehow. C++ implicit conversion is just one way to go; we
> can
> >>> > discuss alternatives in the bug.
> >>>
> >>> The `try` macro in Rust will auto-convert error types that implement
> >>> `Into`, AIUI, but that's not automatic for all error types. I
> haven't
> >>> tried it, but I have seen multiple recommendations for the
> `error_chain`
> >>> crate to make this smoother:
> >>> https://docs.rs/error-chain/0.7.1/error_chain/
> >>>
> >>> It's basically just boilerplate to implement conversions from other
> >>> error types. I wouldn't be surprised if something like that percolates
> >>> into the Rust standard library at some point.
> >>>
> >>> -Ted
> >>> ___
> >>> 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
> >>
> >
> > --
> > Kris Maglione
> > Firefox Add-ons Engineer
> > Mozilla Corporation
> >
> > It's always good to take an orthogonal view of something.  It develops
> > ideas.
> > --Ken Thompson
> >
> >
> ___
> 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

Removing GTK2 widget support?

[lsalzman]

This proposal is in reference to this bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1278282

As it stands currently our builds and testing are done with GTK3, so GTK2 
support is effectively tier 3, with no tracking of regressions other than 
people filing bug reports. GTK2 thus adds to the maintenance burden as well as 
new development overhead of our Linux support, since Linux widget code must be 
added to support both when it is added.

The proposal, to which so far we have tentative agreement of Red Hat and Debian 
is this:

We continue to allow building with GTK2 widget up to and including 52 (ESR). 
Distributions still doing ESR builds with GTK2 have until the next ESR (59) to 
start using GTK3. As soon as 53, though, we would start removing support for 
building with GTK2 widget.

I would be interested to hear if there are significant reasons why we would not 
want to do this. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Introducing mozilla::Result for better error handling

[Nicolas B. Pierron]

On 12/22/2016 06:53 AM, Eric Rahm wrote:

I like the idea of pulling in some Rusty concepts, but I'm concerned about
adding yet another early return macro -- absolutely no arguments on the new
type, just the |MOZ_TRY| macro. In practice these have lead to security
issues (UAF, etc) and memory leaks in the C++ world (I'm looking at you
NS_ENSURE). These aren't hypothetical issues, I've run into them both
working on memshrink and sec issues in Firefox.


I personally like this Result<> class, as it force the user to unwrap the 
result if they need it, and thus one cannot simply miss interpret / ignore 
the returned value. Which could also lead to another spectrum of security 
issues.



A reasonable defense is that we should RAII-all-the-things, and believe me
I get it, but we're working on a 20 year old C++ codebase at this point and
we have to deal with what we have.


We have a template for that! [1]

I think this is worth mentioning based on the low number of uses of 
MakeScopeExit in Gecko (~30).


[1] http://searchfox.org/mozilla-central/source/mfbt/ScopeExit.h

> If we really want the benefits of Rust
> we should be writing components in Rust, not trying to make C++ look like
> Rust, but you know, without the memory safety guarantees.

Unfortunately the problem is always a question of priority, and making our 
life a bit safer with incremental pieces _feels like_ less investment.


Now, if you know who I should contact to rewrite SpiderMonkey in Rust, I 
would be happy to contribute to such project to avoid the pitfalls and costs 
we are seeing today.



-e

On Wed, Dec 21, 2016 at 9:53 AM, Ted Mielczarek  wrote:


On Wed, Dec 21, 2016, at 12:30 PM, Jason Orendorff wrote:

The implicit conversion solves a real problem. Imagine these two
operations
have two different error types:

 MOZ_TRY(JS_DoFirstThing()); // JS::Error&
 MOZ_TRY(mozilla::pkix::DoSecondThing()); // pkix::Error

We don't want our error-handling scheme getting in the way of using them
together. So we need a way of unifying the two error types: a shared base
class, perhaps, or a variant.

Experience with Rust says that MOZ_TRY definitely needs to address this
problem somehow. C++ implicit conversion is just one way to go; we can
discuss alternatives in the bug.


The `try` macro in Rust will auto-convert error types that implement
`Into`, AIUI, but that's not automatic for all error types. I haven't
tried it, but I have seen multiple recommendations for the `error_chain`
crate to make this smoother:
https://docs.rs/error-chain/0.7.1/error_chain/

It's basically just boilerplate to implement conversions from other
error types. I wouldn't be surprised if something like that percolates
into the Rust standard library at some point.

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




--
Nicolas B. Pierron
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform