I’m saying that a param defined as {…} confuses the closure compiler when you
have the rest redefined as an array anywhere but the first line of the
function. It seems like a bug in the closure compiler.
Changing:
rest = Array.prototype.slice.call(arguments, 0);
to:
var rest = Array.prototype.slice.call(arguments, 0);
also makes the error go away, but we do get a reassignment warning.
I’m not sure what declaring a @param as {…} actually accomplishes in terms of
type checking.
> On Sep 7, 2018, at 10:02 AM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> Are you saying some recent change to the compiler is now generating:
> @param {...} rest
>
> If so, what changed caused that output? If not, why did it not fail before?
>
> We should be generating whatever Google says we should generate for rest
> parameters. Although I did ponder the impact of having Royale's trace not
> take extra parameters. Then folks would have to concat strings before
> calling trace.
>
> -Alex
>
> On 9/6/18, 11:58 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>
> It looks like the problem is caused by:
> * @param {...} rest
>
> What would happen if we remove the @param or change it to @param {*=} rest?
>
> Both of those work.
>
>> On Sep 7, 2018, at 8:35 AM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>>
>> But first, I'm not sure your idea is going to work in all cases. See if you
>> get the same problem in JewelExample.
>
>
>
