More elegant constructors and parameterization:

I've been working on a mass balance reconciler which at its base works with vectors representing molar flows of chemical components, which can change for different systems. This seems like an ideal use case for LabelledArrays, and while I've worked with this package for years as an easy way to parameterize vectors, this project required me to make extensive use of this packages internals, particularly the "Syms" parameter which is the last parameter of many. Fighting with this and the constructors became so painful I basically gave up and wrote my own wrapper.

Coming out of this, I can't help but appreciate how elegant NamedTuple is, they simply wrap an existing Tuple type with a tuple of symbols, and the constructor is very wrapper-like: NamedTuple{Syms}(x::Tuple). I built my own named-wrapped array class with based on this philosophy (with some help from this package and ComponentArrays). When translated to the nomenclature of this package, the structure was something like this:

struct LArray{Syms,D<:AbstractArray,T,N} <: AbstractArray{T,N}
    data::D
    function LArray{Syms}(data::D) where {Syms,T,N,D<:AbstractArray{T,N}} 
        @assert Syms isa NTuple{L,Symbol} where L "Expected an NTuple{N,Symbol} for first parameter"
        @assert length(Syms) == length(data) "Number of elements must match the number of names"
        return new{Syms,D,T,N}(data)
    end
end
LArray{Syms,D}(data) where D<:AbstractArray = LArray{Syms}(convert(D, data))

The key was to have the first parameter be Syms (the tuple of symbols) and the second being D (the array being wrapped) the rest of the parameters are inferred at construction and are only used for subtyping into AbstractArray{T,N}. LArray{Syms} was the only constructor I needed most of the time (and I didn't need the @LArray macros either), the rest of the time, LArray{Syms,D} was sufficient. Moreover, the parameters {Syms,D} were the only ones needed for dispatch, making the objects far easier to work with.

This simple change was such a dramatic QoL improvement for me, that I'd be willing to attempt to implement this as a 2.0 PR. Although, I'm not sure there would be an appetite for a change like this. If there isn't, I might have to make yet another package that attaches labels to arrays but more along the style of NamedTuples (to which this packages was the closest one I could find). I just wanted to check in with you over what your thoughts about this were.

No source files or tests are named. First review the existing constructors, Syms parameter handling, and @LArray macros against the proposed LArray{Syms} and LArray{Syms,D} forms; implementation should wait for agreement on whether this is a 2.0 API change and what compatibility and tests define done.