## digitalmars.D - An implication operator and shift operators

- Kari Salminen <Kari_member pathlink.com> Oct 08 2004
- Stewart Gordon <smjg_1998 yahoo.com> Oct 08 2004
- "Olaf" <nobody nowhere.nowhere> Nov 07 2004

Hi, here are a few thoughts on an implication operator and shift operators: - Implication operator: I suggest an implication operator to the language (Taken straight from the Eiffel language): (x implies y) == (x ? y : true) So this would be similar to the AndAnd i.e. && and OrOr i.e. || operators in the way that it wouldn't necessarily always evaluate both of its parameters. Probably implies wouldn't be the most logical choice seeing that in D And, Xor, Or etc are not named And, Xor, Or but &, ^ and | so maybe using => for meaning implication would suffice? (I know, I know, probably not because it would make it more errorprone to write => when meaning >= for an example when comparing some values). And I also know that the implication operator would be mostly just syntactical sugar but it would help readability if used when needed. Does anyone have any good ideas what to name the implication-operator - I mean what characters to choose for it in the D language, should it ever be taken into it? - Shift operators: There's a point about shift operators I don't get yet, but it's probably just me :). Please enlighten me... We have << (left shift) and >> (signed right shift) and >>> (unsigned right shift). Then why don't we have <<< (unsigned left shift)? --- Kari Salminen kaasalm NOSPAM at utu dot fi To email me take out the spaces, NOSPAM and replace at with ' ' and dot with '.'

Oct 08 2004

Kari Salminen wrote: <snip>Probably implies wouldn't be the most logical choice seeing that in D And, Xor, Or etc are not named And, Xor, Or but &, ^ and | so maybe using => for meaning implication would suffice? (I know, I know, probably not because it would make it more errorprone to write => when meaning >= for an example when comparing some values). And I also know that the implication operator would be mostly just syntactical sugar but it would help readability if used when needed.

I guess so....There's a point about shift operators I don't get yet, but it's probably just me :). Please enlighten me... We have << (left shift) and >> (signed right shift) and >>> (unsigned right shift). Then why don't we have <<< (unsigned left shift)?

Because the sign bit just falls off the end regardless. Stewart.

Oct 08 2004

"Kari Salminen" <Kari_member pathlink.com> wrote in message news:ck69v8$1luh$1 digitaldaemon.com...Hi, here are a few thoughts on an implication operator and shift operators: - Implication operator: I suggest an implication operator to the language (Taken straight from the Eiffel language): (x implies y) == (x ? y : true) So this would be similar to the AndAnd i.e. && and OrOr i.e. || operators in the way that it wouldn't necessarily always evaluate both of its parameters. Probably implies wouldn't be the most logical choice seeing that in D And, Xor, Or etc are not named And, Xor, Or but &, ^ and | so maybe using => for meaning implication would suffice? (I know, I know, probably not because it would make it more errorprone to write => when meaning >= for an example when comparing some values). And I also know that the implication operator would be mostly just syntactical sugar but it would help readability if used when needed. Does anyone have any good ideas what to name the implication-operator - I mean what characters to choose for it in the D language, should it ever be taken into it? <cut>

x=>y is equivalent to !x||y: x y x=>y !x||y FALSE FALSE TRUE TRUE FALSE TRUE TRUE TRUE TRUE FALSE FALSE FALSE TRUE TRUE TRUE TRUE Whether that would merit an operator of its own? Dunno...

Nov 07 2004