Re: [webkit-dev] How we enable template functions

[JF Bastien]

I'd suggest considering what it'll look like when we're migrating to
concepts in C++20.

Here's an example for our bitwise_cast:
https://github.com/jfbastien/bit_cast/blob/master/bit_cast.h#L10

Notice the 3 ways to enable. There's also the option of using enable_if on
the return value, or as a defaulted function parameter, but I'm not a huge
fan of either.

On Tue, Aug 22, 2017 at 9:13 PM, Chris Dumez  wrote:

> I personally prefer std::enable_if<>. For e.g.
>
> template int>::value>
> Class Foo { }
>
> I don’t like that something inside the body of a class / function would
> cause a template to be enabled or not.
>
> --
>  Chris Dumez
>
>
>
>
> On Aug 22, 2017, at 8:34 PM, Keith Miller  wrote:
>
> Hello fellow WebKittens,
>
> I’ve noticed over time that we don’t have standard way that we enable
> versions of template functions/classes (flasses?). For the most part it
> seems that people use std::enable_if, although, it seems like it is
> attached to every possible place in the function/class.
>
> I propose that we choose a standard way to conditionally enable a template.
>
> There are a ton of options; my personal favorite is to add the following
> macro:
>
> #define ENABLE_TEMPLATE_IF(condition) static_assert(condition, “template
> disabled”)
>
> Then have every function do:
>
> template
> void foo(…)
> {
>ENABLE_TEMPLATE_IF(std::is_same::value);
>…
> }
>
> And classes:
>
> template
> class Foo {
>ENABLE_TEMPLATE_IF(std::is_same::value);
> };
>
> I like this proposal because it doesn’t obstruct the signature/declaration
> of the function/class but it’s still obvious when the class is enabled.
> Obviously, I think we should require that this macro is the first line of
> the function or class for visibility. Does anyone else have thoughts or
> ideas?
>
> Cheers,
> Keith
>
> P.S. in case you are wondering why this macro works (ugh C++), it’s
> because if there is any compile time error in a template it cannot be
> selected as the final candidate. In my examples, if you provided a type
> other than int foo/Foo could not be selected because the static_assert
> condition would be false, which is a compile error.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] How we enable template functions

[Chris Dumez]

I personally prefer std::enable_if<>. For e.g.

template::value>
Class Foo { }

I don’t like that something inside the body of a class / function would cause a 
template to be enabled or not.

--
 Chris Dumez




> On Aug 22, 2017, at 8:34 PM, Keith Miller  wrote:
> 
> Hello fellow WebKittens,
> 
> I’ve noticed over time that we don’t have standard way that we enable 
> versions of template functions/classes (flasses?). For the most part it seems 
> that people use std::enable_if, although, it seems like it is attached to 
> every possible place in the function/class.
> 
> I propose that we choose a standard way to conditionally enable a template.
> 
> There are a ton of options; my personal favorite is to add the following 
> macro:
> 
> #define ENABLE_TEMPLATE_IF(condition) static_assert(condition, “template 
> disabled”)
> 
> Then have every function do:
> 
> template
> void foo(…)
> {
>ENABLE_TEMPLATE_IF(std::is_same::value);
>…
> }
> 
> And classes:
> 
> template
> class Foo {
>ENABLE_TEMPLATE_IF(std::is_same::value);
> };
> 
> I like this proposal because it doesn’t obstruct the signature/declaration of 
> the function/class but it’s still obvious when the class is enabled. 
> Obviously, I think we should require that this macro is the first line of the 
> function or class for visibility. Does anyone else have thoughts or ideas?
> 
> Cheers,
> Keith
> 
> P.S. in case you are wondering why this macro works (ugh C++), it’s because 
> if there is any compile time error in a template it cannot be selected as the 
> final candidate. In my examples, if you provided a type other than int 
> foo/Foo could not be selected because the static_assert condition would be 
> false, which is a compile error.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] How we enable template functions

[Keith Miller]

Hello fellow WebKittens,

I’ve noticed over time that we don’t have standard way that we enable versions 
of template functions/classes (flasses?). For the most part it seems that 
people use std::enable_if, although, it seems like it is attached to every 
possible place in the function/class.

I propose that we choose a standard way to conditionally enable a template.

There are a ton of options; my personal favorite is to add the following macro:

#define ENABLE_TEMPLATE_IF(condition) static_assert(condition, “template 
disabled”)

Then have every function do:

template
void foo(…)
{
ENABLE_TEMPLATE_IF(std::is_same::value);
…
}

And classes:

template
class Foo {
ENABLE_TEMPLATE_IF(std::is_same::value);
};

I like this proposal because it doesn’t obstruct the signature/declaration of 
the function/class but it’s still obvious when the class is enabled. Obviously, 
I think we should require that this macro is the first line of the function or 
class for visibility. Does anyone else have thoughts or ideas?

Cheers,
Keith

P.S. in case you are wondering why this macro works (ugh C++), it’s because if 
there is any compile time error in a template it cannot be selected as the 
final candidate. In my examples, if you provided a type other than int foo/Foo 
could not be selected because the static_assert condition would be false, which 
is a compile error.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] "webkit-patch upload --no-review" submits to EWS by default

[Keith Miller]

Does it make sense to have a --wip option that’s basically --no-review / don’t 
run EWS? There are times I upload clearly broken patches for early analysis 
that don’t need to be run on EWS.

Cheers,
Keith

> On Aug 14, 2017, at 2:16 PM, Daniel Bates  wrote:
> 
> Hi all,
> 
> Just a heads up. Following r220715 
> , "webkit-patch upload --no-review" 
> and "webkit-patch post-commits --no-review" now submits a patch(es) for EWS 
> analysis by default. You no longer need to open the Bugzilla bug and click 
> the Submit for EWS button to do this on your --no-review patch(es). Pass 
> --no-ews if you want to opt into the old behavior of posting a patch(es) 
> without review and without submitting them to EWS.
> 
> Dan
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Question regarding per-file BSD license text

[Geoffrey Garen]

> My understanding is that if a non-Apple contributor adds a new file, their 
> affiliation should only be reflected in the copyright line and NOT in the BSD 
> license text itself (which reads "APPLE INC."), because the latter is a 
> "per-file copy of a project-wide license". Could someone confirm whether or 
> not this is correct?

Correct.

Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Question regarding per-file BSD license text

[Kirsling, Ross]

Hi all,

I have a simple question about the license text included in each source file.

My understanding is that if a non-Apple contributor adds a new file, their 
affiliation should only be reflected in the copyright line and NOT in the BSD 
license text itself (which reads "APPLE INC."), because the latter is a 
"per-file copy of a project-wide license". Could someone confirm whether or not 
this is correct?

I believe this is what's implied by "preferred license text" at 
https://webkit.org/contributing-code/#develop-your-changes, but it's not 100% 
spelled out.
I do see a handful of exceptions in the codebase, where "THE COPYRIGHT HOLDER" 
or "GOOGLE INC." or "UNIVERSITY OF SZEGED" is used instead, but the vast 
majority of files are in alignment.

(Incidentally, it looks like we also need to update the paragraph I linked to 
reflect the WebKitLegacy move.)

Thanks,
Ross
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev