Positive

[Alix Pexton]

Sean Kelly wrote:
> 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.
> 
> Sounds like range-restricted values, which people have been asking for 
> as a language feature for ages.  The idea has merit.
> 
>> 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?
> 
> See below.
> 
>> 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.
> 
> So you're saying the problem with contracts here is code duplication? 
> I'm not sure I follow.
> 
>> 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.
> 
> To be fair, there's one check for each time such a value is constructed 
> or altered.  So you're simply assuming that the checked value will be 
> constructed and then never altered.  But how is this different from 
> using contracts?
> 
> I like the idea of checked values for safety, but I think efficiency 
> concerns would prevent me from using them for actual work.  For example, 
> let's say that I'm performing a bunch of computations.  I only really 
> want to check whether the result is in range--I don't care about the 
> intermediate values.  So I'd be inclined to forgo the use of checked 
> values for the actual work and simply return a checked type at the end. 
>  But this is exactly how contracts work!  Why would I bother with 
> checked values if I can do the same checking in in/out clauses?
> 
>> 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.
> 
> It's clearly as important to describe the attributes of a variable in 
> math as it is in programming.  So mathematicians settled on the notation 
> you mention, and programmers have largely settled on the use of 
> contracts.  There may still be some value in more math-like notation in 
> programming, but I don't personally see much of a need for it in this 
> case.  Like Walter, I'd continue to use contracts unless some compelling 
> reason can be provided for using this notation instead.
> 
> 
> Sean

Using contracts breaks down as soon as you miss one. For most cases you 
might get away with it because all the contracted functions behave but 
if you don't find that one case where the uncontracted function fails 
before you do a release build then your executable is going to ship with 
a bug.
If it is the type that is constrained to a set of values then those 
constraints ought to bound up with the type and not distributed 
haphazardly through all the code that processes them.
Class invariants are already in the right place (ie inside the class) 
and the use of positive!(T), and similar, is in my view like adding a 
type invariant without having to wrap a concrete type in a class.

As for the dot vs. pling syntax war, I never liked the pling because it 
says "NOT" to me. At first glance the dot does look better to my eye.

A...