Re: defining in What is the proper way in D2?
On Sun, 11 Sep 2011 18:11:11 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 09/11/2011 11:12 PM, Jonathan M Davis wrote:
On Sunday, September 11, 2011 14:00:55 Charles Hixson wrote:
On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
charleshi...@earthlink.net wrote:
I can't figure it out from
http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
// I assume your data structure looks like this
class Node(Key, Data)
{
Key k;
Node!(Key, Data) left, right;
int level;
// ...
void opBinary!(in)(Key k)
{
if (level == 0) return false;
if (k key) return k in left;
if (key k) return k in right;
return true;
}
}
VOID?? I'm going to presume that this should have been bool.
Otherwise, thanks. That was they syntax I couldn't figure out from the
docs.
And, yeah. That's what it looks like. My find code was wrong, because
it should have referenced the node, so what I need to do is move the
cod
into the node class. But it was the syntax of defining the opBinary
specialization that was hanging me up. (For some reason I have a hard
time wrapping my mind around template code.)
The in operator normally returns a pointer to the value that you're
trying
to find (and returns null if it's not there). Making it return bool may
work,
but it's going to be a problem for generic code.
-1
I think the fact that in for AAs returns a pointer is a mistake and
ugly in the first place and any generic code that relies on any
container to return a raw internal pointer is flawed by itself imho.
That reminds me, I should write opIn for dcollections maps. It will
return a cursor (not a pointer).
Hm... probably have to overload cursor.opStar and opCast(bool) at that
point too for the sake of generic code...
-Steve
Re: defining in What is the proper way in D2?
On Mon, 12 Sep 2011 00:11:11 +0200, Timon Gehr timon.g...@gmx.ch wrote: I think the fact that in for AAs returns a pointer is a mistake and ugly in the first place and any generic code that relies on any container to return a raw internal pointer is flawed by itself imho. If D had a Nullable struct, that would likely be a much better return type for 'in'. The thing is, we do have a nullable!T type: T*. This is simply a case of having a wrench and needing a hammer. -- Simen
Re: defining in What is the proper way in D2?
On Mon, 12 Sep 2011 10:10:35 -0400, Simen Kjaeraas simen.kja...@gmail.com wrote: On Mon, 12 Sep 2011 00:11:11 +0200, Timon Gehr timon.g...@gmx.ch wrote: I think the fact that in for AAs returns a pointer is a mistake and ugly in the first place and any generic code that relies on any container to return a raw internal pointer is flawed by itself imho. If D had a Nullable struct, that would likely be a much better return type for 'in'. The thing is, we do have a nullable!T type: T*. This is simply a case of having a wrench and needing a hammer. No, the advantage of using a pointer is, you can change the value without incurring another lookup. A nullable struct does not have that advantage. I think the correct return type for that should be a cursor (i.e. a single-element range which can be used to refer to that element at a later time). This allows even more functionality, such as removing the element, or referring to both the key and value. -Steve
Re: defining in What is the proper way in D2?
On 09/12/2011 04:17 PM, Steven Schveighoffer wrote: On Mon, 12 Sep 2011 10:10:35 -0400, Simen Kjaeraas simen.kja...@gmail.com wrote: On Mon, 12 Sep 2011 00:11:11 +0200, Timon Gehr timon.g...@gmx.ch wrote: I think the fact that in for AAs returns a pointer is a mistake and ugly in the first place and any generic code that relies on any container to return a raw internal pointer is flawed by itself imho. If D had a Nullable struct, that would likely be a much better return type for 'in'. The thing is, we do have a nullable!T type: T*. This is simply a case of having a wrench and needing a hammer. No, the advantage of using a pointer is, you can change the value without incurring another lookup. A nullable struct does not have that advantage. A decent compiler has that advantage without requiring programmers to abuse the 'in' operator. I think the correct return type for that should be a cursor (i.e. a single-element range which can be used to refer to that element at a later time). This allows even more functionality, such as removing the element, or referring to both the key and value. The correct return type for 'in' is bool. But the functionality you propose could be quite useful indeed.
Re: defining in What is the proper way in D2?
On Mon, 12 Sep 2011 10:24:52 -0400, Timon Gehr timon.g...@gmx.ch wrote: On 09/12/2011 04:17 PM, Steven Schveighoffer wrote: On Mon, 12 Sep 2011 10:10:35 -0400, Simen Kjaeraas simen.kja...@gmail.com wrote: On Mon, 12 Sep 2011 00:11:11 +0200, Timon Gehr timon.g...@gmx.ch wrote: I think the fact that in for AAs returns a pointer is a mistake and ugly in the first place and any generic code that relies on any container to return a raw internal pointer is flawed by itself imho. If D had a Nullable struct, that would likely be a much better return type for 'in'. The thing is, we do have a nullable!T type: T*. This is simply a case of having a wrench and needing a hammer. No, the advantage of using a pointer is, you can change the value without incurring another lookup. A nullable struct does not have that advantage. A decent compiler has that advantage without requiring programmers to abuse the 'in' operator. I think the correct return type for that should be a cursor (i.e. a single-element range which can be used to refer to that element at a later time). This allows even more functionality, such as removing the element, or referring to both the key and value. The correct return type for 'in' is bool. But the functionality you propose could be quite useful indeed. I agree the term 'in' doesn't accurately describe the function I propose. But then again, AA doesn't provide any other means to avoid double-lookup. I think having a different member function to do the same thing, and re-purposing 'in' to just return bool would be fine. This should be entirely possible, since AA's are now at least extendable by the library. -Steve
Re: defining in What is the proper way in D2?
On 09/12/2011 04:34 PM, Steven Schveighoffer wrote:
On Mon, 12 Sep 2011 10:24:52 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 09/12/2011 04:17 PM, Steven Schveighoffer wrote:
On Mon, 12 Sep 2011 10:10:35 -0400, Simen Kjaeraas
simen.kja...@gmail.com wrote:
On Mon, 12 Sep 2011 00:11:11 +0200, Timon Gehr timon.g...@gmx.ch
wrote:
I think the fact that in for AAs returns a pointer is a mistake and
ugly in the first place and any generic code that relies on any
container to return a raw internal pointer is flawed by itself imho.
If D had a Nullable struct, that would likely be a much better return
type for 'in'. The thing is, we do have a nullable!T type: T*.
This is simply a case of having a wrench and needing a hammer.
No, the advantage of using a pointer is, you can change the value
without incurring another lookup. A nullable struct does not have that
advantage.
A decent compiler has that advantage without requiring programmers to
abuse the 'in' operator.
I think the correct return type for that should be a cursor (i.e. a
single-element range which can be used to refer to that element at a
later time). This allows even more functionality, such as removing the
element, or referring to both the key and value.
The correct return type for 'in' is bool. But the functionality you
propose could be quite useful indeed.
I agree the term 'in' doesn't accurately describe the function I
propose. But then again, AA doesn't provide any other means to avoid
double-lookup.
The compiler could do it, because most cases of double-lookup are
recognized trivially.
I think having a different member function to do the same
thing, and re-purposing 'in' to just return bool would be fine. This
should be entirely possible, since AA's are now at least extendable by
the library.
-Steve
+1. That would be great, because it would eliminate a case of operator
overloading abuse sitting right in the language's core. Also, it would
open up opportunities to reuse the operator for other built-in types.
if(a in [1,5,7,11]){}
is so much better and DRYer than
if(a==1 || a==5 || a==7 || a==11) {}
Re: defining in What is the proper way in D2?
On Mon, 12 Sep 2011 11:02:20 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 09/12/2011 04:34 PM, Steven Schveighoffer wrote:
On Mon, 12 Sep 2011 10:24:52 -0400, Timon Gehr timon.g...@gmx.ch
wrote:
On 09/12/2011 04:17 PM, Steven Schveighoffer wrote:
On Mon, 12 Sep 2011 10:10:35 -0400, Simen Kjaeraas
simen.kja...@gmail.com wrote:
On Mon, 12 Sep 2011 00:11:11 +0200, Timon Gehr timon.g...@gmx.ch
wrote:
I think the fact that in for AAs returns a pointer is a mistake
and
ugly in the first place and any generic code that relies on any
container to return a raw internal pointer is flawed by itself imho.
If D had a Nullable struct, that would likely be a much better return
type for 'in'. The thing is, we do have a nullable!T type: T*.
This is simply a case of having a wrench and needing a hammer.
No, the advantage of using a pointer is, you can change the value
without incurring another lookup. A nullable struct does not have that
advantage.
A decent compiler has that advantage without requiring programmers to
abuse the 'in' operator.
I think the correct return type for that should be a cursor (i.e. a
single-element range which can be used to refer to that element at a
later time). This allows even more functionality, such as removing the
element, or referring to both the key and value.
The correct return type for 'in' is bool. But the functionality you
propose could be quite useful indeed.
I agree the term 'in' doesn't accurately describe the function I
propose. But then again, AA doesn't provide any other means to avoid
double-lookup.
The compiler could do it, because most cases of double-lookup are
recognized trivially.
I think having a different member function to do the same
thing, and re-purposing 'in' to just return bool would be fine. This
should be entirely possible, since AA's are now at least extendable by
the library.
-Steve
+1. That would be great, because it would eliminate a case of operator
overloading abuse sitting right in the language's core. Also, it would
open up opportunities to reuse the operator for other built-in types.
if(a in [1,5,7,11]){}
is so much better and DRYer than
if(a==1 || a==5 || a==7 || a==11) {}
That still would need special treatment, because in should be fast (O(lgn)
or better), and in on any array is O(n).
I'd say the array had to be a literal, or guaranteed sorted to support
in. I'm not sure that's a great thing.
But in order to do all this, we have to consider that a *lot* of code
relies on a in AA returning a pointer.
I almost think it's too late to make that kind of change (have a in AA
return bool instead of a pointer).
One more point: it's technically not abuse, since a in AA does evaluate to
a bool value meaning a is in the AA. It's overloading :)
-Steve
Re: defining in What is the proper way in D2?
On 09/12/2011 05:16 PM, Steven Schveighoffer wrote:
On Mon, 12 Sep 2011 11:02:20 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 09/12/2011 04:34 PM, Steven Schveighoffer wrote:
On Mon, 12 Sep 2011 10:24:52 -0400, Timon Gehr timon.g...@gmx.ch
wrote:
On 09/12/2011 04:17 PM, Steven Schveighoffer wrote:
On Mon, 12 Sep 2011 10:10:35 -0400, Simen Kjaeraas
simen.kja...@gmail.com wrote:
On Mon, 12 Sep 2011 00:11:11 +0200, Timon Gehr timon.g...@gmx.ch
wrote:
I think the fact that in for AAs returns a pointer is a mistake
and
ugly in the first place and any generic code that relies on any
container to return a raw internal pointer is flawed by itself imho.
If D had a Nullable struct, that would likely be a much better return
type for 'in'. The thing is, we do have a nullable!T type: T*.
This is simply a case of having a wrench and needing a hammer.
No, the advantage of using a pointer is, you can change the value
without incurring another lookup. A nullable struct does not have that
advantage.
A decent compiler has that advantage without requiring programmers to
abuse the 'in' operator.
I think the correct return type for that should be a cursor (i.e. a
single-element range which can be used to refer to that element at a
later time). This allows even more functionality, such as removing the
element, or referring to both the key and value.
The correct return type for 'in' is bool. But the functionality you
propose could be quite useful indeed.
I agree the term 'in' doesn't accurately describe the function I
propose. But then again, AA doesn't provide any other means to avoid
double-lookup.
The compiler could do it, because most cases of double-lookup are
recognized trivially.
I think having a different member function to do the same
thing, and re-purposing 'in' to just return bool would be fine. This
should be entirely possible, since AA's are now at least extendable by
the library.
-Steve
+1. That would be great, because it would eliminate a case of operator
overloading abuse sitting right in the language's core. Also, it would
open up opportunities to reuse the operator for other built-in types.
if(a in [1,5,7,11]){}
is so much better and DRYer than
if(a==1 || a==5 || a==7 || a==11) {}
That still would need special treatment, because in should be fast
(O(lgn) or better), and in on any array is O(n).
O(n) is just fine, because that is the fastest way of searching an
arbitrary array.
I'd say the array had to be a literal, or guaranteed sorted to support
in. I'm not sure that's a great thing.
But in order to do all this, we have to consider that a *lot* of code
relies on a in AA returning a pointer.
What code? I think many people don't notice that it returns a pointer,
because they expect it to return bool.
I almost think it's too late to make that kind of change (have a in AA
return bool instead of a pointer).
One more point: it's technically not abuse, since a in AA does evaluate
to a bool value meaning a is in the AA. It's overloading :)
-Steve
auto foo(){
auto x=a in aa;
return x;
}
Re: defining in What is the proper way in D2?
On Mon, 12 Sep 2011 11:23:36 -0400, Timon Gehr timon.g...@gmx.ch wrote:
On 09/12/2011 05:16 PM, Steven Schveighoffer wrote:
On Mon, 12 Sep 2011 11:02:20 -0400, Timon Gehr timon.g...@gmx.ch
wrote:
On 09/12/2011 04:34 PM, Steven Schveighoffer wrote:
On Mon, 12 Sep 2011 10:24:52 -0400, Timon Gehr timon.g...@gmx.ch
wrote:
On 09/12/2011 04:17 PM, Steven Schveighoffer wrote:
On Mon, 12 Sep 2011 10:10:35 -0400, Simen Kjaeraas
simen.kja...@gmail.com wrote:
On Mon, 12 Sep 2011 00:11:11 +0200, Timon Gehr timon.g...@gmx.ch
wrote:
I think the fact that in for AAs returns a pointer is a mistake
and
ugly in the first place and any generic code that relies on any
container to return a raw internal pointer is flawed by itself
imho.
If D had a Nullable struct, that would likely be a much better
return
type for 'in'. The thing is, we do have a nullable!T type: T*.
This is simply a case of having a wrench and needing a hammer.
No, the advantage of using a pointer is, you can change the value
without incurring another lookup. A nullable struct does not have
that
advantage.
A decent compiler has that advantage without requiring programmers to
abuse the 'in' operator.
I think the correct return type for that should be a cursor (i.e. a
single-element range which can be used to refer to that element at a
later time). This allows even more functionality, such as removing
the
element, or referring to both the key and value.
The correct return type for 'in' is bool. But the functionality you
propose could be quite useful indeed.
I agree the term 'in' doesn't accurately describe the function I
propose. But then again, AA doesn't provide any other means to avoid
double-lookup.
The compiler could do it, because most cases of double-lookup are
recognized trivially.
I think having a different member function to do the same
thing, and re-purposing 'in' to just return bool would be fine. This
should be entirely possible, since AA's are now at least extendable by
the library.
-Steve
+1. That would be great, because it would eliminate a case of operator
overloading abuse sitting right in the language's core. Also, it would
open up opportunities to reuse the operator for other built-in types.
if(a in [1,5,7,11]){}
is so much better and DRYer than
if(a==1 || a==5 || a==7 || a==11) {}
That still would need special treatment, because in should be fast
(O(lgn) or better), and in on any array is O(n).
O(n) is just fine, because that is the fastest way of searching an
arbitrary array.
No it's not fine. Even if you think it is, you will never get this past
Andrei (or me).
a in b should be fast, it's already associated with efficiency.
I'd say the array had to be a literal, or guaranteed sorted to support
in. I'm not sure that's a great thing.
But in order to do all this, we have to consider that a *lot* of code
relies on a in AA returning a pointer.
What code? I think many people don't notice that it returns a pointer,
because they expect it to return bool.
I use it whenever I use AA's to avoid double lookup. Look in any code
that uses AA's and cares about efficiency:
if(auto v = a in b)
{
*v = newval;
}
else
{
b[a] = newval;
}
I almost think it's too late to make that kind of change (have a in AA
return bool instead of a pointer).
One more point: it's technically not abuse, since a in AA does evaluate
to a bool value meaning a is in the AA. It's overloading :)
-Steve
auto foo(){
auto x=a in aa;
return x;
}
if(foo())
works just fine ;)
-Steve
Re: defining in What is the proper way in D2?
On Monday, September 12, 2011 17:23:36 Timon Gehr wrote: On 09/12/2011 05:16 PM, Steven Schveighoffer wrote: I'd say the array had to be a literal, or guaranteed sorted to support in. I'm not sure that's a great thing. But in order to do all this, we have to consider that a *lot* of code relies on a in AA returning a pointer. What code? I think many people don't notice that it returns a pointer, because they expect it to return bool. The documentation is quite clear that in returns a pointer which is null if the item isn't there, so there's going to be code that relies on that fact. - Jonathan M Davis
Re: defining in What is the proper way in D2?
On Mon, 12 Sep 2011 00:00:55 +0300, Charles Hixson
charleshi...@earthlink.net wrote:
On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
charleshi...@earthlink.net wrote:
I can't figure it out from
http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
// I assume your data structure looks like this
class Node(Key, Data)
{
Key k;
Node!(Key, Data) left, right;
int level;
// ...
void opBinary!(in)(Key k)
{
if (level == 0) return false;
if (k key) return k in left;
if (key k) return k in right;
return true;
}
}
VOID?? I'm going to presume that this should have been bool.
Otherwise, thanks. That was they syntax I couldn't figure out from the
docs.
Sorry. Shouldn't have tried this while tired.
--
Best regards,
Vladimirmailto:vladi...@thecybershadow.net
Re: defining in What is the proper way in D2?
On 9/11/11 10:02 PM, Charles Hixson wrote:
What is the proper way to define the in operation in D2?
For containers, you typically want to use opBinaryRight:
---
bool opBinaryRight(string op : in)(ElemType e) const {
return …;
}
---
David
Re: defining in What is the proper way in D2?
On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
charleshi...@earthlink.net wrote:
I can't figure it out from
http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
// I assume your data structure looks like this
class Node(Key, Data)
{
Key k;
Node!(Key, Data) left, right;
int level;
// ...
void opBinary!(in)(Key k)
{
if (level == 0)return false;
if (k key)return k in left;
if (key k)return k in right;
return true;
}
}
--
Best regards,
Vladimirmailto:vladi...@thecybershadow.net
Re: defining in What is the proper way in D2?
On 9/11/11 10:25 PM, Vladimir Panteleev wrote: void opBinary!(in)(Key k) Shouldn't that be »void opBinary(string op : in)(Key k)«? Also, you probably want to use opBinaryRight, because opBinary hooks »if (container in key)«. David
Re: defining in What is the proper way in D2?
On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
charleshi...@earthlink.net wrote:
I can't figure it out from
http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
// I assume your data structure looks like this
class Node(Key, Data)
{
Key k;
Node!(Key, Data) left, right;
int level;
// ...
void opBinary!(in)(Key k)
{
if (level == 0) return false;
if (k key) return k in left;
if (key k) return k in right;
return true;
}
}
VOID?? I'm going to presume that this should have been bool.
Otherwise, thanks. That was they syntax I couldn't figure out from the
docs.
And, yeah. That's what it looks like. My find code was wrong, because
it should have referenced the node, so what I need to do is move the cod
into the node class. But it was the syntax of defining the opBinary
specialization that was hanging me up. (For some reason I have a hard
time wrapping my mind around template code.)
Re: defining in What is the proper way in D2?
On 09/11/2011 01:33 PM, David Nadlinger wrote: On 9/11/11 10:25 PM, Vladimir Panteleev wrote: void opBinary!(in)(Key k) Shouldn't that be »void opBinary(string op : in)(Key k)«? Also, you probably want to use opBinaryRight, because opBinary hooks »if (container in key)«. David And thanks for THIS, too. I'd just started to wonder about the order of the syntax. After all, the key is in the container, but not conversely. Charles
Re: defining in What is the proper way in D2?
On Sunday, September 11, 2011 14:00:55 Charles Hixson wrote:
On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
charleshi...@earthlink.net wrote:
I can't figure it out from
http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
// I assume your data structure looks like this
class Node(Key, Data)
{
Key k;
Node!(Key, Data) left, right;
int level;
// ...
void opBinary!(in)(Key k)
{
if (level == 0) return false;
if (k key) return k in left;
if (key k) return k in right;
return true;
}
}
VOID?? I'm going to presume that this should have been bool.
Otherwise, thanks. That was they syntax I couldn't figure out from the
docs.
And, yeah. That's what it looks like. My find code was wrong, because
it should have referenced the node, so what I need to do is move the cod
into the node class. But it was the syntax of defining the opBinary
specialization that was hanging me up. (For some reason I have a hard
time wrapping my mind around template code.)
The in operator normally returns a pointer to the value that you're trying
to find (and returns null if it's not there). Making it return bool may work,
but it's going to be a problem for generic code. That's like making
opBinary!* return a type different than the types being multiplied. It's just
not how the operator is supposed to be used and could cause problems.
- Jonathan M Davis
Re: defining in What is the proper way in D2?
On 9/11/11 11:12 PM, Jonathan M Davis wrote: The in operator normally returns a pointer to the value that you're trying to find (and returns null if it's not there). Making it return bool may work, but it's going to be a problem for generic code. That's like making opBinary!* return a type different than the types being multiplied. It's just not how the operator is supposed to be used and could cause problems. - Jonathan M Davis +1, I once ran into a bug because of which I used bool instead, but that one should be fixed since quite some time now. David
Re: defining in What is the proper way in D2?
On 09/11/2011 11:12 PM, Jonathan M Davis wrote:
On Sunday, September 11, 2011 14:00:55 Charles Hixson wrote:
On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
charleshi...@earthlink.net wrote:
I can't figure it out from
http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
// I assume your data structure looks like this
class Node(Key, Data)
{
Key k;
Node!(Key, Data) left, right;
int level;
// ...
void opBinary!(in)(Key k)
{
if (level == 0) return false;
if (k key) return k in left;
if (key k) return k in right;
return true;
}
}
VOID?? I'm going to presume that this should have been bool.
Otherwise, thanks. That was they syntax I couldn't figure out from the
docs.
And, yeah. That's what it looks like. My find code was wrong, because
it should have referenced the node, so what I need to do is move the cod
into the node class. But it was the syntax of defining the opBinary
specialization that was hanging me up. (For some reason I have a hard
time wrapping my mind around template code.)
The in operator normally returns a pointer to the value that you're trying
to find (and returns null if it's not there). Making it return bool may work,
but it's going to be a problem for generic code.
-1
I think the fact that in for AAs returns a pointer is a mistake and
ugly in the first place and any generic code that relies on any
container to return a raw internal pointer is flawed by itself imho.
That's like making
opBinary!* return a type different than the types being multiplied. It's just
not how the operator is supposed to be used and could cause problems.
short a,b;
static assert(!is(typeof(a * b) == short));
Re: defining in What is the proper way in D2?
On Monday, September 12, 2011 00:11:11 Timon Gehr wrote:
On 09/11/2011 11:12 PM, Jonathan M Davis wrote:
On Sunday, September 11, 2011 14:00:55 Charles Hixson wrote:
On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
charleshi...@earthlink.net wrote:
I can't figure it out from
http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
// I assume your data structure looks like this
class Node(Key, Data)
{
Key k;
Node!(Key, Data) left, right;
int level;
// ...
void opBinary!(in)(Key k)
{
if (level == 0) return false;
if (k key) return k in left;
if (key k) return k in right;
return true;
}
}
VOID?? I'm going to presume that this should have been bool.
Otherwise, thanks. That was they syntax I couldn't figure out from
the
docs.
And, yeah. That's what it looks like. My find code was wrong,
because
it should have referenced the node, so what I need to do is move the
cod
into the node class. But it was the syntax of defining the opBinary
specialization that was hanging me up. (For some reason I have a hard
time wrapping my mind around template code.)
The in operator normally returns a pointer to the value that you're
trying to find (and returns null if it's not there). Making it return
bool may work, but it's going to be a problem for generic code.
-1
I think the fact that in for AAs returns a pointer is a mistake and
ugly in the first place and any generic code that relies on any
container to return a raw internal pointer is flawed by itself imho.
It's an issue of efficiency. It's more efficient to grab the item once, getting
null if it's not there, then it is to check if it's there and then grab it.
Being a systems language, D is _very_ interested in efficiency. Keeping the
pointer returned from in around for much after the call is likely to be bad
code (and can certainly lead to problems), but there's nothing unsafe about
the pointer in and of itself.
That's like making
opBinary!* return a type different than the types being multiplied.
It's just not how the operator is supposed to be used and could cause
problems.
short a,b;
static assert(!is(typeof(a * b) == short));
Those are primitive types, not user-defined types. They are also effectively
derived types in terms of how they function. There's a big difference between
returning a derived type and returning a completely different type.
- Jonathan M Davis
Re: defining in What is the proper way in D2?
On 09/11/2011 02:12 PM, Jonathan M Davis wrote:
On Sunday, September 11, 2011 14:00:55 Charles Hixson wrote:
On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
charleshi...@earthlink.net wrote:
I can't figure it out from
http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
// I assume your data structure looks like this
class Node(Key, Data)
{
Key k;
Node!(Key, Data) left, right;
int level;
// ...
void opBinary!(in)(Key k)
{
if (level == 0) return false;
Path: digitalmars.com!not-for-mail
From: Charles Hixsoncharleshi...@earthlink.net
Newsgroups: digitalmars.D.learn
Subject: Re: defining in What is the proper way in D2?
Date: Sun, 11 Sep 2011 14:09:57 -0700
Organization: Digital Mars
Lines: 15
Message-ID:j4j83k$ree$1...@digitalmars.com
References:j4j45h$iti$1...@digitalmars.com
op.v1nu0fdrtuz...@cybershadow.mshome.net j4j5uq$m8n$1...@digitalmars.com
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: digitalmars.com 1315775412 28110 66.245.57.66 (11 Sep 2011 21:10:12
GMT)
X-Complaints-To: use...@digitalmars.com
NNTP-Posting-Date: Sun, 11 Sep 2011 21:10:12 + (UTC)
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.21)
Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13
In-Reply-To:j4j5uq$m8n$1...@digitalmars.com
Xref: digitalmars.com digitalmars.D.learn:29434
On 09/11/2011 01:33 PM, David Nadlinger wrote:
On 9/11/11 10:25 PM, Vladimir Panteleev wrote:
void opBinary!(in)(Key k)
Shouldn't that be »void opBinary(string op : in)(Key k)«? Also, you
probably want to use opBinaryRight, because opBinary hooks »if
(container in key)«.
David
And thanks for THIS, too. I'd just started to wonder about the order of
the syntax. After all, the key is in the container, but not conversely.
if (k key) return k in left;
if (key k) return k in right;
return true;
}
}
VOID?? I'm going to presume that this should have been bool.
Otherwise, thanks. That was they syntax I couldn't figure out from the
docs.
And, yeah. That's what it looks like. My find code was wrong, because
it should have referenced the node, so what I need to do is move the cod
into the node class. But it was the syntax of defining the opBinary
specialization that was hanging me up. (For some reason I have a hard
time wrapping my mind around template code.)
The in operator normally returns a pointer to the value that you're trying
to find (and returns null if it's not there). Making it return bool may work,
but it's going to be a problem for generic code. That's like making
opBinary!* return a type different than the types being multiplied. It's just
not how the operator is supposed to be used and could cause problems.
- Jonathan M Davis
OK, but what if the container is supposed to be opaque to external
observers, but you still want to be able to tell whether it contains a
particular item? Doesn't returning a pointer violate encapsulation?
Also, the compiler complained about the declaration, causing me to
currently substitute, thus:
// bool opBinaryRight!(in)(Key k)
bool opBinaryRight(string op)(Key k) if (op == in)
I swiped that code from std.container.d (which also returns a bool).
As what I'm doing is pretty much like a standard container, this seemed
like a reasonable place to look. I sure hope that this doesn't mean I
need to instantiate every use of in. If that's the case I might be
better off just staying with find.
Re: defining in What is the proper way in D2?
On Sunday, September 11, 2011 15:28:38 Charles Hixson wrote:
On 09/11/2011 02:12 PM, Jonathan M Davis wrote:
On Sunday, September 11, 2011 14:00:55 Charles Hixson wrote:
On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
charleshi...@earthlink.net wrote:
I can't figure it out from
http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
// I assume your data structure looks like this
class Node(Key, Data)
{
Key k;
Node!(Key, Data) left, right;
int level;
// ...
void opBinary!(in)(Key k)
{
if (level == 0) return false;
Path: digitalmars.com!not-for-mail
From: Charles Hixsoncharleshi...@earthlink.net
Newsgroups: digitalmars.D.learn
Subject: Re: defining in What is the proper way in D2?
Date: Sun, 11 Sep 2011 14:09:57 -0700
Organization: Digital Mars
Lines: 15
Message-ID:j4j83k$ree$1...@digitalmars.com
References:j4j45h$iti$1...@digitalmars.com
op.v1nu0fdrtuz...@cybershadow.mshome.net
j4j5uq$m8n$1...@digitalmars.com Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: digitalmars.com 1315775412 28110 66.245.57.66 (11 Sep 2011
21:10:12 GMT) X-Complaints-To: use...@digitalmars.com
NNTP-Posting-Date: Sun, 11 Sep 2011 21:10:12 + (UTC)
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US;
rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13
In-Reply-To:j4j5uq$m8n$1...@digitalmars.com
Xref: digitalmars.com digitalmars.D.learn:29434
On 09/11/2011 01:33 PM, David Nadlinger wrote:
On 9/11/11 10:25 PM, Vladimir Panteleev wrote:
void opBinary!(in)(Key k)
Shouldn't that be »void opBinary(string op : in)(Key k)«? Also, you
probably want to use opBinaryRight, because opBinary hooks »if
(container in key)«.
David
And thanks for THIS, too. I'd just started to wonder about the order of
the syntax. After all, the key is in the container, but not conversely.
if (k key) return k in left;
if (key k) return k in right;
return true;
}
}
VOID?? I'm going to presume that this should have been bool.
Otherwise, thanks. That was they syntax I couldn't figure out from
the
docs.
And, yeah. That's what it looks like. My find code was wrong,
because
it should have referenced the node, so what I need to do is move the
cod
into the node class. But it was the syntax of defining the opBinary
specialization that was hanging me up. (For some reason I have a hard
time wrapping my mind around template code.)
The in operator normally returns a pointer to the value that you're
trying to find (and returns null if it's not there). Making it return
bool may work, but it's going to be a problem for generic code. That's
like making opBinary!* return a type different than the types being
multiplied. It's just not how the operator is supposed to be used and
could cause problems.
- Jonathan M Davis
OK, but what if the container is supposed to be opaque to external
observers, but you still want to be able to tell whether it contains a
particular item? Doesn't returning a pointer violate encapsulation?
Yes and no. It does provide direct access to an element in the container,
which could cause issues if they keep the pointer around (just like with any
iterator or range which has been invalidated by a container being altered).
But if you're looking to stop the element from being altered, all you'd have
to do is make it a pointer to const.
Also, the compiler complained about the declaration, causing me to
currently substitute, thus:
// bool opBinaryRight!(in)(Key k)
bool opBinaryRight(string op)(Key k) if (op == in)
I swiped that code from std.container.d (which also returns a bool).
As what I'm doing is pretty much like a standard container, this seemed
like a reasonable place to look. I sure hope that this doesn't mean I
need to instantiate every use of in. If that's the case I might be
better off just staying with find.
I'm a bit surprised that std.container would have it returning bool, but that
would work for any case where you're just checking for existence. It _is_
inefficient in many cases though, and is not great design IMHO. It may mean
that
templated code is ultimately going to have to use static ifs or template
constraints to check where in returns a pointer, but the value of in is
certainly reduced (albeit not eliminated) when it returns bool.
As for template instantiations, you get a new template instantiation for every
type you try and instantiate a template with a new set of template arguments.
If the only argument to opBinaryRight is the string for the operator, then
it's only going to be instantiated once per operator.
As for sticking with find, you can't implement in such that it's at least as
efficient as searching in balance binary tree (O(log n) I believe), then you
shouldn't
Re: defining in What is the proper way in D2?
On 09/12/2011 12:21 AM, Jonathan M Davis wrote:
On Monday, September 12, 2011 00:11:11 Timon Gehr wrote:
On 09/11/2011 11:12 PM, Jonathan M Davis wrote:
On Sunday, September 11, 2011 14:00:55 Charles Hixson wrote:
On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
charleshi...@earthlink.net wrote:
I can't figure it out from
http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
// I assume your data structure looks like this
class Node(Key, Data)
{
Key k;
Node!(Key, Data) left, right;
int level;
// ...
void opBinary!(in)(Key k)
{
if (level == 0) return false;
if (k key) return k in left;
if (key k) return k in right;
return true;
}
}
VOID?? I'm going to presume that this should have been bool.
Otherwise, thanks. That was they syntax I couldn't figure out from
the
docs.
And, yeah. That's what it looks like. My find code was wrong,
because
it should have referenced the node, so what I need to do is move the
cod
into the node class. But it was the syntax of defining the opBinary
specialization that was hanging me up. (For some reason I have a hard
time wrapping my mind around template code.)
The in operator normally returns a pointer to the value that you're
trying to find (and returns null if it's not there). Making it return
bool may work, but it's going to be a problem for generic code.
-1
I think the fact that in for AAs returns a pointer is a mistake and
ugly in the first place and any generic code that relies on any
container to return a raw internal pointer is flawed by itself imho.
It's an issue of efficiency. It's more efficient to grab the item once, getting
null if it's not there, then it is to check if it's there and then grab it.
Being a systems language, D is _very_ interested in efficiency. Keeping the
pointer returned from in around for much after the call is likely to be bad
code (and can certainly lead to problems), but there's nothing unsafe about
the pointer in and of itself.
AAs are built-in. The optimization you describe is quite easily carried
out by the compiler. And I am quite sure that in the long run, it will
bite us.
Sure. D is a systems language and you should probably be able to have
the (unsafe) functionality. But 'in' is a predicate as in x ∈ M . It is
really supposed to return a bool. I think Andrei even successfully
avoids to mention the fact that it returns a pointer in TDPL.
BTW: Why does the current AA implementation rely on the GC if not for
avoiding dangling pointers escaped by in expressions? I think if it is
the only reason, efficiency concerns cannot be a rationale for the
'feature'.
Re: defining in What is the proper way in D2?
On 09/12/2011 12:28 AM, Charles Hixson wrote:
On 09/11/2011 02:12 PM, Jonathan M Davis wrote:
On Sunday, September 11, 2011 14:00:55 Charles Hixson wrote:
On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
charleshi...@earthlink.net wrote:
I can't figure it out from
http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
// I assume your data structure looks like this
class Node(Key, Data)
{
Key k;
Node!(Key, Data) left, right;
int level;
// ...
void opBinary!(in)(Key k)
{
if (level == 0) return false;
Path: digitalmars.com!not-for-mail
From: Charles Hixsoncharleshi...@earthlink.net
Newsgroups: digitalmars.D.learn
Subject: Re: defining in What is the proper way in D2?
Date: Sun, 11 Sep 2011 14:09:57 -0700
Organization: Digital Mars
Lines: 15
Message-ID:j4j83k$ree$1...@digitalmars.com
References:j4j45h$iti$1...@digitalmars.com
op.v1nu0fdrtuz...@cybershadow.mshome.net j4j5uq$m8n$1...@digitalmars.com
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: digitalmars.com 1315775412 28110 66.245.57.66 (11 Sep 2011
21:10:12 GMT)
X-Complaints-To: use...@digitalmars.com
NNTP-Posting-Date: Sun, 11 Sep 2011 21:10:12 + (UTC)
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US;
rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13
In-Reply-To:j4j5uq$m8n$1...@digitalmars.com
Xref: digitalmars.com digitalmars.D.learn:29434
On 09/11/2011 01:33 PM, David Nadlinger wrote:
On 9/11/11 10:25 PM, Vladimir Panteleev wrote:
void opBinary!(in)(Key k)
Shouldn't that be »void opBinary(string op : in)(Key k)«? Also, you
probably want to use opBinaryRight, because opBinary hooks »if
(container in key)«.
David
And thanks for THIS, too. I'd just started to wonder about the order of
the syntax. After all, the key is in the container, but not conversely.
if (k key) return k in left;
if (key k) return k in right;
return true;
}
}
VOID?? I'm going to presume that this should have been bool.
Otherwise, thanks. That was they syntax I couldn't figure out from the
docs.
And, yeah. That's what it looks like. My find code was wrong, because
it should have referenced the node, so what I need to do is move the cod
into the node class. But it was the syntax of defining the opBinary
specialization that was hanging me up. (For some reason I have a hard
time wrapping my mind around template code.)
The in operator normally returns a pointer to the value that you're
trying
to find (and returns null if it's not there). Making it return bool
may work,
but it's going to be a problem for generic code. That's like making
opBinary!* return a type different than the types being multiplied.
It's just
not how the operator is supposed to be used and could cause problems.
- Jonathan M Davis
OK, but what if the container is supposed to be opaque to external
observers, but you still want to be able to tell whether it contains a
particular item? Doesn't returning a pointer violate encapsulation?
Also, the compiler complained about the declaration, causing me to
currently substitute, thus:
// bool opBinaryRight!(in)(Key k)
That is not valid syntax and probably will never be.
bool opBinaryRight(string op)(Key k) if (op == in)
I swiped that code from std.container.d (which also returns a bool). As
what I'm doing is pretty much like a standard container, this seemed
like a reasonable place to look.
I agree.
I sure hope that this doesn't mean I
need to instantiate every use of in. If that's the case I might be
better off just staying with find.
How do you mean, instantiate it?
Re: defining in What is the proper way in D2?
On Monday, September 12, 2011 01:04:39 Timon Gehr wrote:
On 09/12/2011 12:21 AM, Jonathan M Davis wrote:
On Monday, September 12, 2011 00:11:11 Timon Gehr wrote:
On 09/11/2011 11:12 PM, Jonathan M Davis wrote:
On Sunday, September 11, 2011 14:00:55 Charles Hixson wrote:
On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
charleshi...@earthlink.net wrote:
I can't figure it out from
http://www.digitalmars.com/d/2.0/operatoroverloading.html#Bina
ry
// I assume your data structure looks like this
class Node(Key, Data)
{
Key k;
Node!(Key, Data) left, right;
int level;
// ...
void opBinary!(in)(Key k)
{
if (level == 0) return false;
if (k key) return k in left;
if (key k) return k in right;
return true;
}
}
VOID?? I'm going to presume that this should have been bool.
Otherwise, thanks. That was they syntax I couldn't figure out
from
the
docs.
And, yeah. That's what it looks like. My find code was wrong,
because
it should have referenced the node, so what I need to do is move
the
cod
into the node class. But it was the syntax of defining the
opBinary
specialization that was hanging me up. (For some reason I have a
hard
time wrapping my mind around template code.)
The in operator normally returns a pointer to the value that
you're
trying to find (and returns null if it's not there). Making it
return
bool may work, but it's going to be a problem for generic code.
-1
I think the fact that in for AAs returns a pointer is a mistake and
ugly in the first place and any generic code that relies on any
container to return a raw internal pointer is flawed by itself imho.
It's an issue of efficiency. It's more efficient to grab the item once,
getting null if it's not there, then it is to check if it's there and
then grab it. Being a systems language, D is _very_ interested in
efficiency. Keeping the pointer returned from in around for much after
the call is likely to be bad code (and can certainly lead to problems),
but there's nothing unsafe about the pointer in and of itself.
AAs are built-in. The optimization you describe is quite easily carried
out by the compiler. And I am quite sure that in the long run, it will
bite us.
Sure. D is a systems language and you should probably be able to have
the (unsafe) functionality. But 'in' is a predicate as in x ∈ M . It is
really supposed to return a bool. I think Andrei even successfully
avoids to mention the fact that it returns a pointer in TDPL.
BTW: Why does the current AA implementation rely on the GC if not for
avoiding dangling pointers escaped by in expressions? I think if it is
the only reason, efficiency concerns cannot be a rationale for the
'feature'.
It is no more dangerous than keeping an iterator or range around after its
been invalidated. In fact, it's _exactly_ the same thing. And there's no way
that you're going to get rid of that issue in an efficient manner. That's why
std.container has the stable* functions. Pointers are allowed in SafeD and are
perfectly safe. It's stuff like pointer arithmetic which is unsafe and
disallowed in SafeD.
Yes, there are issues if you keep the pointer around after the container has
been altered, but ranges have exactly the same issue. It's a known and
accepted problem. The solution is to just not keep the pointer around. If a
programmer keeps such a pointer aronud (or keeps a range around after altering
a container with a non-stable* function), then they're risking buggy code.
That doesn't mean that the feature is a bad idea.
- Jonathan M Davis
Re: defining in What is the proper way in D2?
Timon Gehr: AAs are built-in. The optimization you describe is quite easily carried out by the compiler. And I am quite sure that in the long run, it will bite us. With the LDC compiler if you perform an AA lookup, and after one or few lines you do it again, (because you are using an if and you are not using the pointer nature of the return value of in AA), LDC most times uses a single AA lookup. This little group of optimizations were added to LDC just to improve AA usage. With such simple optimizations I think 99% of times you don't need in AA to return a pointer. So probably returning a bool is enough. I don't think I have ever stored the return pointer of in AA, I have used it locally, just to save one AA lookup. Bye, bearophile
Re: defining in What is the proper way in D2?
On 09/11/2011 04:07 PM, Timon Gehr wrote:
On 09/12/2011 12:28 AM, Charles Hixson wrote:
On 09/11/2011 02:12 PM, Jonathan M Davis wrote:
On Sunday, September 11, 2011 14:00:55 Charles Hixson wrote:
On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
charleshi...@earthlink.net wrote:
I can't figure it out from
http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
// I assume your data structure looks like this
class Node(Key, Data)
{
Key k;
Node!(Key, Data) left, right;
int level;
// ...
void opBinary!(in)(Key k)
{
if (level == 0) return false;
Path: digitalmars.com!not-for-mail
From: Charles Hixsoncharleshi...@earthlink.net
Newsgroups: digitalmars.D.learn
Subject: Re: defining in What is the proper way in D2?
Date: Sun, 11 Sep 2011 14:09:57 -0700
Organization: Digital Mars
Lines: 15
Message-ID:j4j83k$ree$1...@digitalmars.com
References:j4j45h$iti$1...@digitalmars.com
op.v1nu0fdrtuz...@cybershadow.mshome.net
j4j5uq$m8n$1...@digitalmars.com
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: digitalmars.com 1315775412 28110 66.245.57.66 (11 Sep 2011
21:10:12 GMT)
X-Complaints-To: use...@digitalmars.com
NNTP-Posting-Date: Sun, 11 Sep 2011 21:10:12 + (UTC)
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US;
rv:1.9.2.21) Gecko/20110831 Iceowl/1.0b2 Icedove/3.1.13
In-Reply-To:j4j5uq$m8n$1...@digitalmars.com
Xref: digitalmars.com digitalmars.D.learn:29434
On 09/11/2011 01:33 PM, David Nadlinger wrote:
On 9/11/11 10:25 PM, Vladimir Panteleev wrote:
void opBinary!(in)(Key k)
Shouldn't that be »void opBinary(string op : in)(Key k)«? Also, you
probably want to use opBinaryRight, because opBinary hooks »if
(container in key)«.
David
And thanks for THIS, too. I'd just started to wonder about the order of
the syntax. After all, the key is in the container, but not conversely.
if (k key) return k in left;
if (key k) return k in right;
return true;
}
}
VOID?? I'm going to presume that this should have been bool.
Otherwise, thanks. That was they syntax I couldn't figure out from the
docs.
And, yeah. That's what it looks like. My find code was wrong, because
it should have referenced the node, so what I need to do is move the
cod
into the node class. But it was the syntax of defining the opBinary
specialization that was hanging me up. (For some reason I have a hard
time wrapping my mind around template code.)
The in operator normally returns a pointer to the value that you're
trying
to find (and returns null if it's not there). Making it return bool
may work,
but it's going to be a problem for generic code. That's like making
opBinary!* return a type different than the types being multiplied.
It's just
not how the operator is supposed to be used and could cause problems.
- Jonathan M Davis
OK, but what if the container is supposed to be opaque to external
observers, but you still want to be able to tell whether it contains a
particular item? Doesn't returning a pointer violate encapsulation?
Also, the compiler complained about the declaration, causing me to
currently substitute, thus:
// bool opBinaryRight!(in)(Key k)
That is not valid syntax and probably will never be.
bool opBinaryRight(string op)(Key k) if (op == in)
I swiped that code from std.container.d (which also returns a bool). As
what I'm doing is pretty much like a standard container, this seemed
like a reasonable place to look.
I agree.
I sure hope that this doesn't mean I
need to instantiate every use of in. If that's the case I might be
better off just staying with find.
How do you mean, instantiate it?
container.binaryOp(in)!(something I haven't figured out yet.
Template syntax doesn't make any sense to me yet. I'm just copying
examples and adapting them with a cut and try and see what works and
what doesn't. More failures than successes.
OTOH, it does seem better than C++ template syntax, but that's VERY
faint praise indeed.
Re: defining in What is the proper way in D2?
On 09/12/2011 02:53 AM, Charles Hixson wrote: On 09/11/2011 04:07 PM, Timon Gehr wrote: How do you mean, instantiate it? container.binaryOp(in)!(something I haven't figured out yet. Template syntax doesn't make any sense to me yet. I'm just copying examples and adapting them with a cut and try and see what works and what doesn't. More failures than successes. OTOH, it does seem better than C++ template syntax, but that's VERY faint praise indeed. You can explicitly instantiate it like this: container.opBinaryRight!in(elem); but you should be able to write elem in container instead, which is the same thing.
Re: defining in What is the proper way in D2?
On 09/11/2011 06:02 PM, Timon Gehr wrote: On 09/12/2011 02:53 AM, Charles Hixson wrote: On 09/11/2011 04:07 PM, Timon Gehr wrote: How do you mean, instantiate it? container.binaryOp(in)!(something I haven't figured out yet. Template syntax doesn't make any sense to me yet. I'm just copying examples and adapting them with a cut and try and see what works and what doesn't. More failures than successes. OTOH, it does seem better than C++ template syntax, but that's VERY faint praise indeed. You can explicitly instantiate it like this: container.opBinaryRight!in(elem); but you should be able to write elem in container instead, which is the same thing. Thanks, both for the reassurance, and for the alternate syntax.
