819523 - Make it possible to pass any TArray (fallible or not) to a const ref taking any other TArray (fallible or not)

Status: RESOLVED FIXED

Description

[Boris Zbarsky [:bzbarsky, bz on IRC]]

Since if people don't cast away const they can't use the allocator anyway.

Comment 1

[Boris Zbarsky [:bzbarsky, bz on IRC]]

Created attachment 690047 [details] [diff] [review]
part 1.  Make it possible to use the various-allocator nsTArrays interchangeably as long as you're working with const objects.

Comment 2

[Boris Zbarsky [:bzbarsky, bz on IRC]]

Created attachment 690049 [details] [diff] [review]
part 2.  Allow Nullable<> of various array types to work sanely.

Peter, I can understand if you don't want to take this black magic....

Comment 3

[Boris Zbarsky [:bzbarsky, bz on IRC]]

Created attachment 690051 [details] [diff] [review]
Part 2, even compiling

Comment 4

[Justin Lebar (not reading bugmail)]

Comment on attachment 690047 [details] [diff] [review]
part 1.  Make it possible to use the various-allocator nsTArrays interchangeably as long as you're working with const objects.

> +  // Allow converting to a const array with a different kind of allocator,
> +  // Since the allocator doesn't matter for const arrays

Would you mind changing the second line so it begins with a lower-case letter and ends with a period?

r=me, and thanks for writing a test!

Comment 5

[Justin Lebar (not reading bugmail)]

Comment on attachment 690051 [details] [diff] [review]
Part 2, even compiling

> +  // mIsNull MUST COME FIRST because otherwise the casting in our array
> +  // conversion operators would shift where it is found in the struct.
> +  bool mIsNull;
>    T mValue;
> -  bool mIsNull;
>  
>  public:
>    Nullable()
>      : mIsNull(true)
>    {}
>  
> -  Nullable(T aValue)
> +  explicit Nullable(T aValue)
>      : mValue(aValue)
>      , mIsNull(false)

-Werror on tinderbox doesn't like the fact that the initialization list's order doesn't match the order of the members.

Comment 6

[Justin Lebar (not reading bugmail)]

Created attachment 693033 [details] [diff] [review]
Follow-up to part 2: Fix initialization list order in Nullable.h.

Comment 7

[Boris Zbarsky [:bzbarsky, bz on IRC]]

Ah, thank you.  Good catch.

I'm being tempted to land part 1 and not worry about part 2, fwiw...

Comment 8

[Justin Lebar (not reading bugmail)]

Comment on attachment 690051 [details] [diff] [review]
Part 2, even compiling

r=me, fwiw.  Are you OK if I land these two patches along with bug 819791?

Comment 9

[Boris Zbarsky [:bzbarsky, bz on IRC]]

Yes, go for it!  Three patches, that is, counting your initializer reordering.

Comment 10

[Justin Lebar (not reading bugmail)]

Landed with followup folded in to part 2.

https://hg.mozilla.org/integration/mozilla-inbound/rev/6ed3f784cdd3
https://hg.mozilla.org/integration/mozilla-inbound/rev/51e3f82d820b

Comment 11

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/6ed3f784cdd3
https://hg.mozilla.org/mozilla-central/rev/51e3f82d820b