On Friday, 31 July 2015 at 16:28:30 UTC, jmh530 wrote:
Looking at the PR also resolved my earlier question. Running
the code as below (do not import std.range) will tell you
exactly what isn't implemented from isInputRange (in this case,
I commented out popFront). Very cool.
template
On Friday, 31 July 2015 at 11:16:48 UTC, Biotronic wrote:
On Thursday, 30 July 2015 at 10:40:59 UTC, Atila Neves wrote:
There's still the problem of having two names for each
constraint: checkInputRange and isInputRange. But... we could
also establish the convention of checkXXX and use string
On Friday, 31 July 2015 at 14:23:28 UTC, Atila Neves wrote:
On Friday, 31 July 2015 at 11:16:48 UTC, Biotronic wrote:
On Thursday, 30 July 2015 at 10:40:59 UTC, Atila Neves wrote:
[...]
Why are there two different things in the first place?
@satisfies!(myConcept, T) should test the
On Thursday, 30 July 2015 at 19:12:27 UTC, jmh530 wrote:
On Thursday, 30 July 2015 at 10:40:59 UTC, Atila Neves wrote:
[...]
I might be overthinking this.
You would still need to define something for checkInputRange.
Are you thinking something simple like
template checkInputRange(R)
{
On Friday, 31 July 2015 at 14:23:28 UTC, Atila Neves wrote:
On Friday, 31 July 2015 at 11:16:48 UTC, Biotronic wrote:
Why can't another template use the very same concept
information to check if a type implements the concept?
e.g.:
@satisfies!(myConcept, MyStruct)
struct MyStruct { /* ... */
On Friday, 31 July 2015 at 14:24:58 UTC, Atila Neves wrote:
Notice however, that (again, in the PR), the real definition
happens only once, in the check function. Then the constraint
is always a trivial `enum MyConstraint =
is(typeof(myCheckFunction));`. It's just a matter of moving the
On Thursday, 30 July 2015 at 10:40:59 UTC, Atila Neves wrote:
There's still the problem of having two names for each
constraint: checkInputRange and isInputRange. But... we could
also establish the convention of checkXXX and use string mixins
to turn this:
@satifies!(isInputRange, MyRange)
On Friday, 31 July 2015 at 11:16:48 UTC, Biotronic wrote:
Why are there two different things in the first place?
@satisfies!(myConcept, T) should test the constraints and give
a sensible error message. This you use to indicate that type T
implements myConcept.
Why can't another template use
On Thursday, 30 July 2015 at 10:40:59 UTC, Atila Neves wrote:
On Wednesday, 29 July 2015 at 20:41:02 UTC, Tofu Ninja wrote:
On Wednesday, 29 July 2015 at 20:26:53 UTC, Tofu Ninja wrote:
If you write:
@satisfies!(isInputRange, MyRange) struct MyRange { ... }
the UDA can check it self, it
On Tuesday, 28 July 2015 at 18:23:02 UTC, Tofu Ninja wrote:
On Tuesday, 28 July 2015 at 13:23:37 UTC, Daniel Kozák wrote:
[...]
I have actually thought about this as well, and a thing that
could actually make this possible is if UDAs could get the
thing they are attached to. I realized it
On Thursday, 30 July 2015 at 10:40:59 UTC, Atila Neves wrote:
You still wouldn't get a better error message here than with:
struct MyRange {
...
static assert(isInputRange!MyRange);
}
It's less typing, but you still wouldn't know why the static
assertion failed. Now, if we make
On Wednesday, 29 July 2015 at 20:41:02 UTC, Tofu Ninja wrote:
On Wednesday, 29 July 2015 at 20:26:53 UTC, Tofu Ninja wrote:
If you write:
@satisfies!(isInputRange, MyRange) struct MyRange { ... }
the UDA can check it self, it really works as expected. Which
is why I suggested a way to get
On Tuesday, 28 July 2015 at 12:49:17 UTC, Atila Neves wrote:
So I missed the boat on the lengthy Rust traits discussion on
the other thread. I confess I didn't have time to read all of
it so forgive me if I bring up something that's already been
said there.
[...]
I went back to my copy of
On 7/29/15 4:25 AM, Roland Hadinger wrote:
@satisfies(isInputRange) struct MyRange { ... }
This is straight from the creative use of what we have mantra that I
think is worth exploring. -- Andrei
On Wednesday, 29 July 2015 at 20:26:53 UTC, Tofu Ninja wrote:
If you write:
@satisfies!(isInputRange, MyRange) struct MyRange { ... }
the UDA can check it self, it really works as expected. Which
is why I suggested a way to get whatever the UDA is attached to
automatically in my other post.
On Wednesday, 29 July 2015 at 14:51:52 UTC, Atila Neves wrote:
On Wednesday, 29 July 2015 at 08:25:04 UTC, Roland Hadinger
wrote:
On Tuesday, 28 July 2015 at 12:49:17 UTC, Atila Neves wrote:
So... instead of having traits / concepts, what I wanted from
D is to be able to do this:
struct
On Tuesday, 28 July 2015 at 12:49:17 UTC, Atila Neves wrote:
So... instead of having traits / concepts, what I wanted from D
is to be able to do this:
struct MyRange: isInputRange { ... }
+1
or
struct MyRange: static isInputRange { ... } // that way classes
could do this too
What about
On Tuesday, 28 July 2015 at 13:10:43 UTC, Atila Neves wrote:
I guess, but not easily. I've written template mixins to do
that before and it was awkward.
What was awkward?
On Wednesday, 29 July 2015 at 06:05:37 UTC, Kagamin wrote:
On Tuesday, 28 July 2015 at 13:10:43 UTC, Atila Neves wrote:
I guess, but not easily. I've written template mixins to do
that before and it was awkward.
What was awkward?
Writing a generic solution that would work for multiple
On Wednesday, 29 July 2015 at 08:25:04 UTC, Roland Hadinger wrote:
On Tuesday, 28 July 2015 at 12:49:17 UTC, Atila Neves wrote:
So... instead of having traits / concepts, what I wanted from
D is to be able to do this:
struct MyRange: isInputRange { ... }
+1
or
struct MyRange: static
On Tuesday, 28 July 2015 at 12:49:17 UTC, Atila Neves wrote:
So... instead of having traits / concepts, what I wanted from D
is to be able to do this:
struct MyRange: isInputRange { ... }
or
struct MyRange: static isInputRange { ... } // that way classes
could do this too
+1
Concept
On Tuesday, 28 July 2015 at 13:23:37 UTC, Daniel Kozák wrote:
I would use something like this:
@interface(InputRange, ...)
struct MyRange { ... }
@interface(InputRange, ...)
class MyClassRange { ... }
I get the change from isInputRange to InputRange, because
isInputRange is like a
On Tue, 28 Jul 2015 12:49:15 +
Atila Neves atila.ne...@gmail.com wrote:
So I missed the boat on the lengthy Rust traits discussion on the
other thread. I confess I didn't have time to read all of it so
forgive me if I bring up something that's already been said there.
Since last
On Tuesday, 28 July 2015 at 13:02:06 UTC, Jack Stouffer wrote:
Overall a great idea!
On Tuesday, 28 July 2015 at 12:49:17 UTC, Atila Neves wrote:
struct MyRange: static isInputRange { ... }
I don't think you even need new syntax to get the error
messages. If you have a static assert in your
So I missed the boat on the lengthy Rust traits discussion on the
other thread. I confess I didn't have time to read all of it so
forgive me if I bring up something that's already been said there.
Since last year, after having written a ton of generic code with
compile-time reflection and
Overall a great idea!
On Tuesday, 28 July 2015 at 12:49:17 UTC, Atila Neves wrote:
struct MyRange: static isInputRange { ... }
I don't think you even need new syntax to get the error messages.
If you have a static assert in your unit tests for
isInputRange!MyType, then theoretically you
On Tuesday, 28 July 2015 at 13:23:37 UTC, Daniel Kozák wrote:
I was thinking about same many times before. With one
difference:
instead of this:
struct MyRange: isInputRange { ... }
I would use something like this:
@interface(InputRange, ...)
struct MyRange { ... }
@interface(InputRange,
27 matches
Mail list logo
