Re: Named template constraints
On Tue, 22 Apr 2014 14:50:44 -0400, monarch_dodra wrote: On Tuesday, 22 April 2014 at 18:35:58 UTC, Steven Schveighoffer wrote: On Tue, 22 Apr 2014 11:36:07 -0400, monarch_dodra wrote: On Tuesday, 22 April 2014 at 15:30:36 UTC, Steven Schveighoffer wrote: Also, an immutable can be initialized that way: immutable int[] = int[].init; Isn't that exactly "R.init" ? Yes, you said if it's an immutable it would fail to compile. I think this is not true. -Steve Ah... you said: Note, is the r2 = R.init needed? Not sure. To whitch I replied: Yes: It R2 has no default init, or is an immutable, then that line will fail to compile. I meant that if you *don't* add the R.init, then the code will *not* compile. EG => R.init is necessary. Sorry for the mixup :/ OH!!! I meant is the whole *line* necessary, not the R.init part :) Note that in my updated version, r is passed in as a parameter to the mock function. This means if R is inout(something), it will be part of the parameters, and you don't need a dummy inout parameter to shut the compiler up. So the r2 = R.init; was just to "keep things the same", but I'm not sure it's necessary to have. It has a comment saying "can define a range object", whereas it could just be "I need a range object to compile the rest of this code" :) -Steve
Re: Named template constraints
On Tuesday, 22 April 2014 at 18:35:58 UTC, Steven Schveighoffer wrote: On Tue, 22 Apr 2014 11:36:07 -0400, monarch_dodra wrote: On Tuesday, 22 April 2014 at 15:30:36 UTC, Steven Schveighoffer wrote: Also, an immutable can be initialized that way: immutable int[] = int[].init; Isn't that exactly "R.init" ? Yes, you said if it's an immutable it would fail to compile. I think this is not true. -Steve Ah... you said: Note, is the r2 = R.init needed? Not sure. To whitch I replied: Yes: It R2 has no default init, or is an immutable, then that line will fail to compile. I meant that if you *don't* add the R.init, then the code will *not* compile. EG => R.init is necessary. Sorry for the mixup :/
Re: Named template constraints
On Tue, 22 Apr 2014 11:36:07 -0400, monarch_dodra wrote: On Tuesday, 22 April 2014 at 15:30:36 UTC, Steven Schveighoffer wrote: Also, an immutable can be initialized that way: immutable int[] = int[].init; Isn't that exactly "R.init" ? Yes, you said if it's an immutable it would fail to compile. I think this is not true. -Steve
Re: Named template constraints
Am 22.04.2014 16:58, schrieb Andrej Mitrovic via Digitalmars-d-learn: On 4/22/14, Tim Holzschuh via Digitalmars-d-learn wrote: What does (inout int = 0) mean/affect here? This was asked recently, see my reponse here: http://forum.dlang.org/post/mailman.102.1396007039.25518.digitalmars-d-le...@puremagic.com Aargh, I'm sorry. Didn't see that one. - Tim
Re: Named template constraints
On 04/22/2014 07:07 AM, Tim Holzschuh via Digitalmars-d-learn wrote:
> read the 'More Templates' chapter of Ali's book (<-- thanks
> for that ;) ).
Yay! :)
> At the section 'Named constraints', there were a definition like this:
>
> template isUsable(T)
> {
> enum isUsable = is ( typeof(
> {
> T obj;
> obj.call();
> obj.otherCall(1);
> obj.ye tAnotherCall();
> }() ) );
> }
That is how Phobos used to be.
> But at Phobos I always see definitions like this (std.range :
> isInputRange):
>
> template isInputRange(R)
> {
> enum bool isInputRange = is(typeof(
> (inout int = 0)
I had noticed that as well and am curious myself. My guess is that it is
a syntax issue where that default parameter list makes it a stronger
delegate syntax. :p
> {
> R r = R.init; // can define a range object
> if (r.empty) {} // can test for empty
> r.popFront(); // can invoke popFront()
> auto h = r.front; // can get the front of the range
> }));
> } What does (inout int = 0) mean/affect here? I created the same
> template for myself just without the (inout int = 0) and it worked (at
> least with a dummy struct).. - Tim
Same here: I cannot find an example where the first version does not
work. (?)
Ali
Re: Named template constraints
On Tuesday, 22 April 2014 at 15:30:36 UTC, Steven Schveighoffer wrote: On Tue, 22 Apr 2014 11:15:14 -0400, monarch_dodra wrote: On Tuesday, 22 April 2014 at 15:06:34 UTC, Steven Schveighoffer wrote: Note, is the r2 = R.init needed? Not sure. Yes: It R2 has no default init, or is an immutable, then that line will fail to compile. I don't believe it's possible to have no 'init'. I think the reason it says '= R.init' is for ranges that have @disable this(). Yes, that's what I meant by "no default init". Guess I got my terms wrong. Sorry. Also, an immutable can be initialized that way: immutable int[] = int[].init; Isn't that exactly "R.init" ? Of course, it wouldn't pass the rest of isInputRange. -Steve In this particular case, probably not (except for, maybe "repeat"?) In any case, it's become the "generic" way of initializing a generic type.
Re: Named template constraints
On 4/22/14, Steven Schveighoffer via Digitalmars-d-learn > I think this can be fixed a different way. Feel free to file a bug / make a pull. :>
Re: Named template constraints
On Tue, 22 Apr 2014 11:15:14 -0400, monarch_dodra wrote: On Tuesday, 22 April 2014 at 15:06:34 UTC, Steven Schveighoffer wrote: Note, is the r2 = R.init needed? Not sure. Yes: It R2 has no default init, or is an immutable, then that line will fail to compile. I don't believe it's possible to have no 'init'. I think the reason it says '= R.init' is for ranges that have @disable this(). Also, an immutable can be initialized that way: immutable int[] = int[].init; Of course, it wouldn't pass the rest of isInputRange. -Steve
Re: Named template constraints
On Tuesday, 22 April 2014 at 15:06:34 UTC, Steven Schveighoffer wrote: Note, is the r2 = R.init needed? Not sure. Yes: It R2 has no default init, or is an immutable, then that line will fail to compile.
Re: Named template constraints
Not sure what InputRange is defined as atm, but I don't think anything should have to define init to be a valid inputrange.
Re: Named template constraints
On Tue, 22 Apr 2014 10:58:41 -0400, Andrej Mitrovic via
Digitalmars-d-learn wrote:
On 4/22/14, Tim Holzschuh via Digitalmars-d-learn
wrote:
What does (inout int = 0) mean/affect here?
This was asked recently, see my reponse here:
http://forum.dlang.org/post/mailman.102.1396007039.25518.digitalmars-d-le...@puremagic.com
I think this can be fixed a different way:
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
(R r)
{
R r2 = R.init; // can define a range object
if (r.empty) {} // can test for empty
r.popFront(); // can invoke popFront()
auto h = r.front; // can get the front of the range
}));
}
Note, is the r2 = R.init needed? Not sure.
-Steve
Re: Named template constraints
On 4/22/14, Tim Holzschuh via Digitalmars-d-learn wrote: > What does (inout int = 0) mean/affect here? This was asked recently, see my reponse here: http://forum.dlang.org/post/mailman.102.1396007039.25518.digitalmars-d-le...@puremagic.com
Named template constraints
Hi there,
I recently read the 'More Templates' chapter of Ali's book (<-- thanks
for that ;) ).
At the section 'Named constraints', there were a definition like this:
template isUsable(T)
{
enum isUsable = is ( typeof(
{
T obj;
obj.call();
obj.otherCall(1);
obj.ye tAnotherCall();
}() ) );
}
But at Phobos I always see definitions like this (std.range : isInputRange):
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
(inout int = 0)
{
R r = R.init; // can define a range object
if (r.empty) {} // can test for empty
r.popFront(); // can invoke popFront()
auto h = r.front; // can get the front of the range
}));
} What does (inout int = 0) mean/affect here? I created the same
template for myself just without the (inout int = 0) and it worked (at
least with a dummy struct).. - Tim
