The practical case is very simple - a formatter accepts a lot of types.

Andrei

On 8/20/10 20:35 CDT, David Simcha wrote:
Hmm. It's worth considering, but I see at least two problems.

1. Do we have a practical use case for it? I don't generally believe in
adding complexity without clear use cases for said complexity.

2. The base interface is OutputRange!(E). If I change the base interface
to OutputRange!(E...), then OutputRange!(uint, double) won't be a
subtype of OutputRange!(uint). This is self-evidently ridiculous. I
could maybe make OutputRangeObject!(E...) inherit from
OutputRange!(E[0]), OutputRange!(E[1]), ..., OutputRange!(E[$ - 1]), but
other than nasty string mixins D doesn't provide a way to inherit from a
tuple of interfaces.

On 8/20/2010 9:26 PM, Shin Fujishiro wrote:
David Simcha<[email protected]> wrote:
In addition to the changes I made last night, I've also made the
following changes:

1. Change name to inputRangeObject/InputRangeObject.
2. Add support for output ranges as outputRangeObject/OutputRangeObject.
3. Remove the now ridiculous looking Hungarian notation on the
interfaces.

http://pastebin.com/U83YNJfJ is where it's at.

Any more comments from anyone, or does this look ready to be checked in?
Could you make OutputRangeObject able to accept multiple element types?

template outputRangeObject(E...) {
auto outputRangeObject(R)(R range) { ... }
}


Shin
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos


_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos

Reply via email to