Positive

[Janderson]

Andrei Alexandrescu wrote:
> Hello,
> 
> 
> (Background: Walter has kindly allowed ".()" as an alternative to the 
> ugly "!()" for template argument specifications.)
> 
> Just a quick question - I am feeling an increasing desire to add a 
> template called Positive to std.typecons. Then Positive.(real) would 
> restrict its values to only positive real numbers etc.
> 
> The implementation would accept conversion from its base type, e.g. 
> Positive.(real) can be constructed from a real. The constructor enforces 
> dynamically the condition. Also, Positive.(real) accepts implicit 
> conversion to real (no checking necessary).
> 
> There are many places in which Positive can be useful, most notably 
> specifications of interfaces. For example:
> 
> Positive.(real) sqrt(Positive.(real) x);
> 
> These specifications are also efficient because checking for positivity 
> is done outside sqrt; if you had a Positive.(real) to start with, there 
> is no cascading checking necessary so there's one test less to do.
> 
> However, there is also the risk that Positive has the same fate the many 
> SafeInt implementation have had in C++: many defined them, nobody used 
> them. What do you think? If you had Positive in std and felt like 
> crunching some numbers, would you use it?
> 
> In order to get things really started, there's already been an exchange 
> with Walter on the matter. His reply was (I haven't asked for 
> permission, but I'm pretty sure he'd agree making it public):
> 
> ==============
> Honestly, I wouldn't use it. I'd rather have an in contract for sqrt 
> that asserts the argument is positive. Also, this opens the door to 
> Negative, NegativeOrZero, ZeroOrInfinity, Odd, Even, Prime, 
> SixOrFifteen, etc.
> ==============
> 
> My answer to that was:
> 
> ==============
> About contracts: Let me explain how I think that's inferior to Positive 
> in two ways.
> 
> 1. Enough functions are defined on positive numbers only, to justify 
> factoring that contract out of the functions themselves.
> 
> 2. The efficiency perk is that when using several such functions 
> together, there's only one check; once in Positive-land, no more checks 
> are necessary.
> 
> About proliferation of types: I don't think that follows at all. Math 
> found positive numbers special enough to dedicate them a special 
> notation (|R with subscript "+"). There's also a special notation for 
> nonzero real numbers (|R with superscript "*"). There is no special 
> notation for any of the sets you mentioned. That is bound to mean 
> something.
> ==============
> 
> I'm interesting in further arguments. This feature is a numbers issue 
> (pun not intended), meaning it will be any good only if enough people 
> find it useful enough to actually use it in their own code and 
> libraries, therefore building momentum behind it.
> 
> 
> Andrei

As others have mentioned.

Why a second class form of range restriction?  Why not a first class 
implementation like ADA's with ranges and subranges as specific 
typedefs?  I know it would be more work for the compiler writer to 
implement (if it can't be done in templates) however I prefer more 
generic solutions then having many once-off solutions that crudely fit 
together.

Being able to simply pick a type that is within the range needed would 
save having to write contracts and static contracts all over the place. 
  It also a great form of documentation.  I would find that useful, 
particularly when working with algorithms that traverse arrays in 
specific sequences such as spacial data structures but need to maintain 
certain constraints.

-Joel