Checking function parameters in Phobos

[inout]

On Monday, 25 November 2013 at 13:01:43 UTC, Simen Kjærås wrote:
> On 2013-11-25 13:00, Marco Leise wrote:
>> Am Fri, 22 Nov 2013 02:55:44 +0100
>> schrieb Simen Kjærås <simen.kjaras at gmail.com>:
>>
>>> On 22.11.2013 00:50, Meta wrote:
>>>> On Thursday, 21 November 2013 at 22:51:43 UTC, inout wrote:
>>>>> What if you have more that just one validation, e.g. 
>>>>> Positive and
>>>>> LessThan42?
>>>>> Is Positive!LessThan42!int the same type as 
>>>>> LessThan42!Positive!int?
>>>>> Implicitly convertible?
>>>>
>>>> Allow multiple validation functions. Then a Validated type 
>>>> is only valid
>>>> if validationFunction1(val) && validationFunction2(val) &&...
>>>>
>>>> Validated!(isPositive, lessThan42, int) validatedInt =
>>>> validate!(isPositive, lessThan42)(34);
>>>> //Do stuff with validatedInt
>>>
>>> I believe inout's point was this, though:
>>>
>>>    Validated!(isPositive, lessThan42, int) i = foo();
>>>
>>>    Validated!(isPositive, int) n = i; // Fails.
>>>    Validated!(lessThan42, isPositive, int) r = i; // Fails.
>>>
>>> This is of course less than optimal.
>>>
>>> If a type such as Validate is to be added to Phobos, these 
>>> problems need
>>> to be fixed first.
>>
>> Can you write a templated assignment operator that
>> accepts any Validated!* instance and builds the set difference
>> of validation functions that are missing on the assigned value?
>> E.g. in the case of n = i: {isPositive} / {isPositive,
>> lessThan42} = emtpy set.
>
> Do you mean this?
>
> Validated!(int, isPositive, lessThan42) a =
>     validated!(isPositive, lessThan42)(13);
> Validated!(int, isPositive) b = a;
> a = b; // Only tests lessThan42
>
> If so, you're mostly right that this should be done. I am 
> however of the opinion that conversions that may throw should 
> be marked appropriately, so this will be the right way:
>
> a = validated!(isPositive, lessThan42)(b); // Only tests 
> lessThan42
>
> New version now available on GitHub:
> http://git.io/hEe0MA
> http://git.io/QEP-kQ
>
> --
>   Simen

I find this to be too verbose to be useful. And you also need to
be very careful not to discard any existing qualifiers on input
and carry them over. This will essentially make any function that
uses them to be templated, while all the instances will be the
same (yet have a different body since no D compiler merges
identical functions).

I still find wrapping int with some type to add a tag to it
without adding any methods is not a great idea - it doesn't scale
well with composition and tag propagation. Any operation that
expects int will essentially discard all the qualifiers.