Re: Return-value-optimization when return type is RefPtr

Kan-Ru Chen (陳侃如)於 2016年5月24日星期二 UTC+8下午4時00分12秒寫道： > I think the current practice is to use already_AddRefed as return > type and return foo.forget() > > Kanru I think that is the legacy when we don't have move semantics. Returning RefPtr won't incur ref-counting overhead and is more expressive

WebRTC Internal IP Address Leakage

Is there any intent at Mozilla to fix this privacy flaw? https://bugzilla.mozilla.org/show_bug.cgi?id=959893 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Group Photo

Here is the group photo from this morning's session: https://www.flickr.com/photos/9361819@N04/27686864545/in/album-72157669699014665/ https://www.flickr.com/photos/9361819@N04/27686865615/in/album-72157669699014665/ -- Adam Roach Principal Platform Engineer Office of the CTO _

Re: Questions about bindings for L20n

On Tuesday, June 14, 2016 at 11:51:16 AM UTC+1, Joe Walker wrote: > I don't think you can say "It's sync unless in which case it's > async". > If that's that case then from the API consumers point of view, then (deep > voodoo withstanding) it's async. As weird as it sounds, I believe that you act