D - opContains
- Patrick Down (7/7) Jan 20 2004 A an operator overload for 'in' would be nice.
- Vathix (3/13) Jan 20 2004 Gets my vote. I was thinking of mentioning it several times. Although, I...
- C (3/10) Jan 20 2004 Very cool!
- Juan C (7/23) Jan 20 2004 I guess if it's an operator "in" makes sense.
- Matthew (6/33) Jan 21 2004 larger
- C (9/45) Jan 21 2004 I don't really like the double use of 'in' , I doubt this will take but ...
- The Lone Haranguer (2/53) Jan 21 2004
- C (12/72) Jan 21 2004 But we already have many operators that dont fall into that category.
- Andy Friesen (5/7) Jan 21 2004 Why?
- Robert (6/13) Jan 21 2004 I don't agree.
- Robert (5/7) Jan 21 2004 Hmm. I've forgot it!
- Patrick Down (3/10) Jan 21 2004 The main reason for this is to be able to completely
- Stephan Wienczny (10/22) Jan 21 2004 I don't think that is possible as in is not used as operator but keyword...
- Patrick Down (3/25) Jan 21 2004 'in' is also used for associative arrays. Read the documentation:
- Matthew (5/27) Jan 21 2004 Even if that is so - and I have to question how it is already managed fo...
A an operator overload for 'in' would be nice. class Foo { bool opContains(char[]) {} } Foo f; if("bar" in f) { }
Jan 20 2004
Patrick Down wrote:A an operator overload for 'in' would be nice. class Foo { bool opContains(char[]) {} } Foo f; if("bar" in f) { }Gets my vote. I was thinking of mentioning it several times. Although, I thought of naming it opIn; opContains is good too.
Jan 20 2004
Very cool! "Patrick Down" <Patrick_member pathlink.com> wrote in message news:bukqnu$1sio$1 digitaldaemon.com...A an operator overload for 'in' would be nice. class Foo { bool opContains(char[]) {} } Foo f; if("bar" in f) { }
Jan 20 2004
I guess if it's an operator "in" makes sense. But if it's a method "contains" is better... if ( f.Contains ( "bar" ) ) ... And personally, I prefer methods rather than bogging a language down with operators. Especially when the operation is not likely to be used in a larger expression, as boolean expressions seldom are. In article <buktne$217e$1 digitaldaemon.com>, C says...Very cool! "Patrick Down" <Patrick_member pathlink.com> wrote in message news:bukqnu$1sio$1 digitaldaemon.com...A an operator overload for 'in' would be nice. class Foo { bool opContains(char[]) {} } Foo f; if("bar" in f) { }
Jan 20 2004
"Juan C" <Juan_member pathlink.com> wrote in message news:bul8ct$2id6$1 digitaldaemon.com...I guess if it's an operator "in" makes sense. But if it's a method "contains" is better... if ( f.Contains ( "bar" ) ) ... And personally, I prefer methods rather than bogging a language down with operators. Especially when the operation is not likely to be used in alargerexpression, as boolean expressions seldom are.In general I agree, but I think "in" will be widely used, especially if we can overload it. I vote for opIn, btw. (Call it what it is)In article <buktne$217e$1 digitaldaemon.com>, C says...Very cool! "Patrick Down" <Patrick_member pathlink.com> wrote in message news:bukqnu$1sio$1 digitaldaemon.com...A an operator overload for 'in' would be nice. class Foo { bool opContains(char[]) {} } Foo f; if("bar" in f) { }
Jan 21 2004
I don't really like the double use of 'in' , I doubt this will take but what about renaming it to 'contains'. char [ int ] hash; if ( hash contains "element" ) { } ? C "Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:bulf2p$2u6r$3 digitaldaemon.com..."Juan C" <Juan_member pathlink.com> wrote in message news:bul8ct$2id6$1 digitaldaemon.com...withI guess if it's an operator "in" makes sense. But if it's a method "contains" is better... if ( f.Contains ( "bar" ) ) ... And personally, I prefer methods rather than bogging a language downoperators. Especially when the operation is not likely to be used in alargerexpression, as boolean expressions seldom are.In general I agree, but I think "in" will be widely used, especially if we can overload it. I vote for opIn, btw. (Call it what it is)In article <buktne$217e$1 digitaldaemon.com>, C says...Very cool! "Patrick Down" <Patrick_member pathlink.com> wrote in message news:bukqnu$1sio$1 digitaldaemon.com...A an operator overload for 'in' would be nice. class Foo { bool opContains(char[]) {} } Foo f; if("bar" in f) { }
Jan 21 2004
If it's not a mathematical operation it shouldn't be an operator. In article <bumcqt$1ad8$1 digitaldaemon.com>, C says...I don't really like the double use of 'in' , I doubt this will take but what about renaming it to 'contains'. char [ int ] hash; if ( hash contains "element" ) { } ? C "Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:bulf2p$2u6r$3 digitaldaemon.com..."Juan C" <Juan_member pathlink.com> wrote in message news:bul8ct$2id6$1 digitaldaemon.com...withI guess if it's an operator "in" makes sense. But if it's a method "contains" is better... if ( f.Contains ( "bar" ) ) ... And personally, I prefer methods rather than bogging a language downoperators. Especially when the operation is not likely to be used in alargerexpression, as boolean expressions seldom are.In general I agree, but I think "in" will be widely used, especially if we can overload it. I vote for opIn, btw. (Call it what it is)In article <buktne$217e$1 digitaldaemon.com>, C says...Very cool! "Patrick Down" <Patrick_member pathlink.com> wrote in message news:bukqnu$1sio$1 digitaldaemon.com...A an operator overload for 'in' would be nice. class Foo { bool opContains(char[]) {} } Foo f; if("bar" in f) { }
Jan 21 2004
But we already have many operators that dont fall into that category. int opCat ( int x) int opIndex ( int x) int opCall ( ) int opApply(int delegate(inout uint) dg) How about , after this one , no more operators ;). C "The Lone Haranguer" <The_member pathlink.com> wrote in message news:bumed2$1cqp$1 digitaldaemon.com...If it's not a mathematical operation it shouldn't be an operator. In article <bumcqt$1ad8$1 digitaldaemon.com>, C says...whatI don't really like the double use of 'in' , I doubt this will take butaabout renaming it to 'contains'. char [ int ] hash; if ( hash contains "element" ) { } ? C "Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:bulf2p$2u6r$3 digitaldaemon.com..."Juan C" <Juan_member pathlink.com> wrote in message news:bul8ct$2id6$1 digitaldaemon.com...withI guess if it's an operator "in" makes sense. But if it's a method "contains" is better... if ( f.Contains ( "bar" ) ) ... And personally, I prefer methods rather than bogging a language downoperators. Especially when the operation is not likely to be used inwelargerexpression, as boolean expressions seldom are.In general I agree, but I think "in" will be widely used, especially ifcan overload it. I vote for opIn, btw. (Call it what it is)In article <buktne$217e$1 digitaldaemon.com>, C says...Very cool! "Patrick Down" <Patrick_member pathlink.com> wrote in message news:bukqnu$1sio$1 digitaldaemon.com...A an operator overload for 'in' would be nice. class Foo { bool opContains(char[]) {} } Foo f; if("bar" in f) { }
Jan 21 2004
The Lone Haranguer wrote:If it's not a mathematical operation it shouldn't be an operator.Why? Besides, set theory has an 'in' operator. I don't think the symbol it uses is a part of normal ASCII, though. -- andy
Jan 21 2004
I don't agree. Indeed, it looks nice, but that's all. I will be satisfied if there is 'member' method as Lisp and Prolog. if(f.member("bar")) { } "Patrick Down" <Patrick_member pathlink.com> wrote in message news:bukqnu$1sio$1 digitaldaemon.com...A an operator overload for 'in' would be nice. class Foo { bool opContains(char[]) {} } Foo f; if("bar" in f) { }
Jan 21 2004
"Patrick Down" <Patrick_member pathlink.com> wrote in message news:bun2pp$2e60$1 digitaldaemon.com...'in' is also used for associative arrays. Read the documentation: http://www.digitalmars.com/d/arrays.htmlHmm. I've forgot it! Indeed, 'opContains' should be supported. I agree.
Jan 21 2004
The main reason for this is to be able to completely emulate the fuctionality of associative arrays. In article <bukqnu$1sio$1 digitaldaemon.com>, Patrick Down says...A an operator overload for 'in' would be nice. class Foo { bool opContains(char[]) {} } Foo f; if("bar" in f) { }
Jan 21 2004
Patrick Down wrote:A an operator overload for 'in' would be nice. class Foo { bool opContains(char[]) {} } Foo f; if("bar" in f) { }I don't think that is possible as in is not used as operator but keyword for contracts. It would make parsing d sources more complicated. Remember: in {} out(result){} body{} Such an operator would be nice, but it should use another identifier. Looking at my keyboard one solution could be ' ' if ("bar" f) {} What do you think
Jan 21 2004
In article <bumklq$1nfm$1 digitaldaemon.com>, Stephan Wienczny says...Patrick Down wrote:'in' is also used for associative arrays. Read the documentation: http://www.digitalmars.com/d/arrays.htmlA an operator overload for 'in' would be nice. class Foo { bool opContains(char[]) {} } Foo f; if("bar" in f) { }I don't think that is possible as in is not used as operator but keyword for contracts. It would make parsing d sources more complicated. Remember:in {} out(result){} body{} Such an operator would be nice, but it should use another identifier. Looking at my keyboard one solution could be ' ' if ("bar" f) {} What do you think
Jan 21 2004
"Stephan Wienczny" <wienczny web.de> wrote in message news:bumklq$1nfm$1 digitaldaemon.com...Patrick Down wrote:Even if that is so - and I have to question how it is already managed for ass arrays if it's too hard - I think it's worth it.A an operator overload for 'in' would be nice. class Foo { bool opContains(char[]) {} } Foo f; if("bar" in f) { }I don't think that is possible as in is not used as operator but keyword for contracts. It would make parsing d sources more complicated. Remember: in {} out(result){} body{}Such an operator would be nice, but it should use another identifier. Looking at my keyboard one solution could be ' ' if ("bar" f) {} What do you thinkNot much
Jan 21 2004