Coding style: Naming parameters in lambda expressions
Hi,
we encountered the question of how to name parameters in lambda expressions.
For regular functions, the coding style implies that parameter naming
should use camelCase with an "a" prefix, and this is also widely done
this way. The coding style does not say anything specifically
concerning lambda expressions at the moment. Actual uses differ at
least between using the a prefix and using no prefix.
Since in most cases, lambda expressions occur within a regular
function, using the a prefix leads to some ambiguity when reading the
code, as one cannot immediately tell whether an a-prefixed identifier
is a parameter to the lambda expression or to the enclosing function
(which may be captured).
For example, one might have:
bool MyFunction(const nsTArray& aFoos, const nsCString &aId) {
if (std::any_of(aFoos.begin(), aFoos.end(), [aId](const Foo& aFoo) {
return aFoo.Id() == aId;
}) {
// do something more...
return true;
}
return false;
}
This is a simple case, where this might not be particularly
problematic, but I find it quite confusing to use aFoo as a lambda
parameter name. Obviously, when not using a prefix, similar
ambiguities with local variable names in the enclosing function may
arise. For some subjective reason, I find this less confusing, but
this may be different for others. Using a different prefix, e.g. l,
leading to calling the lambda parameter lFoo, would resolve this
ambiguity, but one might feel there are too many different prefixes.
While I have some personal preference against the a prefix here, I
think any of these options were acceptable. Maybe this has already
been discussed and concluded before, but not put into the coding style
document?
Simon
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Intent to Ship - Support XCTO: nosniff for navigations
Currently the Support for “X-Content-Type-Options: nosniff“ is limited to CSS and JS resources. In Firefox 70 I intend to enable nosniff support for page navigations by default. If a server's response does not include any mime-type but sets the response header "XCTO: nosniff" then Firefox will prompt the user to download the file instead of trying to sniff the mime-type, eliminating the attack vector of so called mime-confusion attacks. Supporting XCTO: nosniff not only for JS and CSS but also for top-level navigations will create parity with other browsers (Chrome, Safari) who are already supporting XCTO: nosniff for navigations. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1428473 Link to standard: https://fetch.spec.whatwg.org/#x-content-type-options-header Platform coverage: This will be exposed to all platforms. Estimated or target release: Firefox 70 Is this feature enabled by default in sandboxed iframes? N/A DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1571415 Do other browser engines implement this? Yes Secure contexts: This feature isn’t restricted to Secure Contexts. Bug implementing and enabling this feature: - https://bugzilla.mozilla.org/show_bug.cgi?id=1469592 - https://bugzilla.mozilla.org/show_bug.cgi?id=1570658 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Ship - Support XCTO: nosniff for navigations
On Thu, Sep 5, 2019 at 6:21 AM Sebastian Streich wrote: > Link to standard: > https://fetch.spec.whatwg.org/#x-content-type-options-header That bit of the standard doesn't describe this behavior--it still only talks about scripts and style. Is there an issue or PR to update the spec to describe this blocking? Is this feature enabled by default in sandboxed iframes? N/A > Will we still try to sniff if you frame the victim resource instead of navigating to it at the top level? Checking the code this does apply to TYPE_SUBDOCUMENT and I don't see any "if sandboxed" checks , so I think your answer here should be "Yes: it applies to sandboxed frames by default". ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Ship - Support XCTO: nosniff for navigations
On 9/5/19 9:20 AM, Sebastian Streich wrote: In Firefox 70 I intend to enable nosniff support for page navigations by default. We're still doing stream converters for navigations even if that header is sent. Is that intended? I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1579176 to track that. If a server's response does not include any mime-type but sets the response header "XCTO: nosniff" then Firefox will prompt the user to download the file Is that definitely known to be true? Based on code inspection it looks like this case will set the type to UNKNOWN_CONTENT_TYPE, then keep trying to do stream conversion things with it 20 times in a row (or whatever the "general.document_open_conversion_depth_limit" pref is set to), and then kick it over to the helper app handler. After that what happens depends on whether the user might have a helper app defined for that type and so forth. If we actually mean to force a download, we should probably be doing so explicitly. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Nika Layzell and Kris Maglione are now XPCOM peers
On Wed, Sep 4, 2019, 11:33 Nathan Froyd Kris noticed that Nika was going to become an XPCOM peer and, not > wanting to be left out, volunteered (yes, really). Kris has worked on > modernizing the component manager and various thread-related > improvements. > To be clear, I volunteered because erahm said "we really need more XPCOM peers" :p > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style: Naming parameters in lambda expressions
I remain against aFoo style. I still think it's low-signal-high-noise, and
doesn't provide value that modern syntax highlighting doesn't provide for
those who find it useful.
I'm absolutely opposed to adding a new prefix. That would be moving even
further down the path of our proprietary code-smell.
On Thu, Sep 5, 2019 at 6:15 AM Simon Giesecke wrote:
> Hi,
>
> we encountered the question of how to name parameters in lambda
> expressions.
>
> For regular functions, the coding style implies that parameter naming
> should use camelCase with an "a" prefix, and this is also widely done
> this way. The coding style does not say anything specifically
> concerning lambda expressions at the moment. Actual uses differ at
> least between using the a prefix and using no prefix.
>
> Since in most cases, lambda expressions occur within a regular
> function, using the a prefix leads to some ambiguity when reading the
> code, as one cannot immediately tell whether an a-prefixed identifier
> is a parameter to the lambda expression or to the enclosing function
> (which may be captured).
>
> For example, one might have:
>
> bool MyFunction(const nsTArray& aFoos, const nsCString &aId) {
> if (std::any_of(aFoos.begin(), aFoos.end(), [aId](const Foo& aFoo) {
> return aFoo.Id() == aId;
> }) {
> // do something more...
> return true;
> }
> return false;
> }
>
> This is a simple case, where this might not be particularly
> problematic, but I find it quite confusing to use aFoo as a lambda
> parameter name. Obviously, when not using a prefix, similar
> ambiguities with local variable names in the enclosing function may
> arise. For some subjective reason, I find this less confusing, but
> this may be different for others. Using a different prefix, e.g. l,
> leading to calling the lambda parameter lFoo, would resolve this
> ambiguity, but one might feel there are too many different prefixes.
>
> While I have some personal preference against the a prefix here, I
> think any of these options were acceptable. Maybe this has already
> been discussed and concluded before, but not put into the coding style
> document?
>
> Simon
> ___
> 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: Coding style: Naming parameters in lambda expressions
Yeah, let's not add a new prefix please.
I don't like aFoo either, though it's everywhere so consistency is
better than nothing :/.
That being said, it shouldn't be hard to write some clang plugin or such
that automatically renames function arguments to stop using aFoo, should
we want to do that... Just throwing it in the air, and volunteering if
we agreed to do that ;)
-- Emilio
On 9/5/19 10:55 PM, Jeff Gilbert wrote:
I remain against aFoo style. I still think it's low-signal-high-noise, and
doesn't provide value that modern syntax highlighting doesn't provide for
those who find it useful.
I'm absolutely opposed to adding a new prefix. That would be moving even
further down the path of our proprietary code-smell.
On Thu, Sep 5, 2019 at 6:15 AM Simon Giesecke wrote:
Hi,
we encountered the question of how to name parameters in lambda
expressions.
For regular functions, the coding style implies that parameter naming
should use camelCase with an "a" prefix, and this is also widely done
this way. The coding style does not say anything specifically
concerning lambda expressions at the moment. Actual uses differ at
least between using the a prefix and using no prefix.
Since in most cases, lambda expressions occur within a regular
function, using the a prefix leads to some ambiguity when reading the
code, as one cannot immediately tell whether an a-prefixed identifier
is a parameter to the lambda expression or to the enclosing function
(which may be captured).
For example, one might have:
bool MyFunction(const nsTArray& aFoos, const nsCString &aId) {
if (std::any_of(aFoos.begin(), aFoos.end(), [aId](const Foo& aFoo) {
return aFoo.Id() == aId;
}) {
// do something more...
return true;
}
return false;
}
This is a simple case, where this might not be particularly
problematic, but I find it quite confusing to use aFoo as a lambda
parameter name. Obviously, when not using a prefix, similar
ambiguities with local variable names in the enclosing function may
arise. For some subjective reason, I find this less confusing, but
this may be different for others. Using a different prefix, e.g. l,
leading to calling the lambda parameter lFoo, would resolve this
ambiguity, but one might feel there are too many different prefixes.
While I have some personal preference against the a prefix here, I
think any of these options were acceptable. Maybe this has already
been discussed and concluded before, but not put into the coding style
document?
Simon
___
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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
