On Thursday, April 14, 2016 01:09:19 PM James Fairbanks wrote:
> 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?You can use an inner constructor to enforce consistency, see the end of http://docs.julialang.org/en/stable/manual/performance-tips/#avoid-fields-with-abstract-containers. > 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? It's simpler than that: the penalty for gathering the arguments to foo(x...) = bar(x...) into a tuple goes away if foo itself gets inlined. (There's a little more going on that that, but this gives the general idea.) It just passes on the challenge to the downstream function bar, but if bar itself is inlined or specialized (perhaps by @generated) to handle a particular number of arguments, you're fine. --Tim
