fx norm deprecation

[CarloLucibello]

fix some deprecations for the normalization layers

[DhairyaLGandhi]

Seems fine, but it should follow the guidelines of being faithful to the fields (lambda comes first etc) and should only populate the new fields with the same defaults as the regular constructors

[CarloLucibello]

Seems fine, but it should follow the guidelines of being faithful to the fields (lambda comes first etc)

It's a deprecation, so it should match the old constructor on one side and the new one on the other side

and should only populate the new fields with the same defaults as the regular constructors

It's a deprecation, so it should match the old behavior

[DhairyaLGandhi]

Right, the new constructor should only add the new fields, not change the order of the remaining ones.

[CarloLucibello]

Right, the new constructor should only add the new fields, not change the order of the remaining ones.

This seems rather arbitrary.

Number of channels is the very first (and typically the only) argument we pass to the user-facing constructor, BatchNorm(64), so seems natural to have it as the first field in the struct definition, other's fields positions are just shifted by one.

[DhairyaLGandhi]

These are different constructors though. They are different from the channel one.

[CarloLucibello]

These are just the constructors implicitly defined by the types

[DhairyaLGandhi]

Yes they are defined per our struct definition. They are convenient for when someone wants to use different array or number types.

[CarloLucibello]

moved the number of channels in last position

[CarloLucibello]

should be ready to merge @DhairyaLGandhi

[DhairyaLGandhi]

We will probably want the depwarns in rather quickly. Hopefully we can resolve the fields situation, it's a pretty long list atm

bors r+

[bors]

Build succeeded:

• buildkite/flux-dot-jl