the (pseudo)app requires that lo and hi be permitted to have different numeric types all the uses for lo and hi require they be promoted to one or the other or a third type, but their original type info must be retained throughout I thought pre-positioning the promote_type() result in a parameter would allow smoother sailing via dispatch (so everything would not have to go through a type-indiscriminate 'routing')
I get the inherent anti-pattern of it, and that it makes unavailable a bunch of good stuff. I dislike the constraint so, and I'm guessing that ultimately the 'requirement' would be met with small groups of 'different' numeric types, and the within-group distinction might be size of representation only. More interesting: is it possible to put a computed value as a parameterized type's parameter without making a factory? On Tuesday, December 29, 2015 at 12:09:34 PM UTC-5, Stefan Karpinski wrote: > > I'm a little confused – do you want the types of lo and hi to match or > allow them to be different? Abstractly typed fields are going to be > inefficient and largely defeat the optimizations that immutability would > normally allow. > > On Mon, Dec 28, 2015 at 11:38 PM, Jeffrey Sarnoff <[email protected] > <javascript:>> wrote: > >> is there a way to do accomplish this? >> >> immutable Ivl{B<:AkoBound, R<:Real} # R <-- >> promote_type(typeof(lo),typeof(hi)) >> lo::Real # allow lo, hi >> to differ in type (subtypes of Real) >> hi::Real >> ?? >> end >> >> >
