Correction:
> So the general thing happening here is:
>
>
> type A{B,C}
> c::C
> end
>
> function A{B,C}(c::C{B})
> return A{B,typeof(c)}(c)
> end
>
>
> Rest of original message:
> I can't add the constraint that B and C must be "consistent" to the type
> definitions. However, the constructor can use that constraint in the type
> annotation on its arguments.
> In that case there is nothing to stop you from making an "inconsistent"
> instance of type A{B,C}, but anything that comes out of the outer
> constructor will be consistent.
> What is the PL name for this notion of consistency?
>
>
>> Your 1D constructor could just dispatch to this with SparseArray(data,
>> (dims,))
>>
>> If you add @inline in front of the getindex/setindex! functions, you may
>> be
>> able to eliminate the splatting penalty, and you won't need the 1D
>> specializations.
>>
>
> Why does @inline eliminate the splatting penalty specifically? Does
> inlining allow some later (LLVM?) pass to remove the operations to gather
> the indices into a tuple and the splat them back out again (replacing them
> with a no-op?)? In that case is it important that the other methods of
> getindex are also defined with @inline?
>
> This is interesting, I don't usually pay this much attention to the types
> I use.
>
> Thanks,
> James
>
