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 <[email protected]>:
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.
