www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD 0.148 - regular expressions

reply "Walter Bright" <newshound digitalmars.com> writes:
The match expressions are gone. Based on the feedback, people didn't want D 
to adopt perl'ish notation or implicitly defined variables. Instead, foreach 
statements now allow implicit typing of the key/value declarations, and the 
if statement now can declare a variable for the result (an adaptation of Ben 
Hinkle's idea). 
Feb 25 2006
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright schrieb am 2006-02-26:
 Instead, foreach statements now allow implicit typing of the key/value
declarations

The only missing implicit typing: # template square(auto x) # { # auto square = x * x; # } <g> Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFEAXyk3w+/yD4P9tIRAlmMAKDOAaV/R2cXBx8stfaO5Hw86tgPsQCgpAbu HeEgU5DtCYRndFs/FGVFgZw= =57jc -----END PGP SIGNATURE-----
Feb 26 2006
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
That looks absolutely amazing.  I want.

-[Unknown]


 Walter Bright schrieb am 2006-02-26:
 Instead, foreach statements now allow implicit typing of the key/value
declarations

The only missing implicit typing: # template square(auto x) # { # auto square = x * x; # } <g> Thomas

Feb 26 2006
parent James Dunne <james.jdunne gmail.com> writes:
Unknown W. Brackets wrote:
 That looks absolutely amazing.  I want.
 
 -[Unknown]
 
 
 Walter Bright schrieb am 2006-02-26:

 Instead, foreach statements now allow implicit typing of the 
 key/value declarations

[snip] The only missing implicit typing: # template square(auto x) # { # auto square = x * x; # } <g> Thomas


OMG, teh ambiguity! =P Anyway, you really can't do this at the moment? Oh well, probably because auto parameters don't exist yet (AFAIK). -- Regards, James Dunne
Feb 26 2006
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

 The match expressions are gone. Based on the feedback, people didn't want
 D to adopt perl'ish notation or implicitly defined variables. Instead,
 foreach statements now allow implicit typing of the key/value
 declarations, and the if statement now can declare a variable for the
 result (an adaptation of Ben Hinkle's idea).

I liked the idea (match expressions), just not the operator, and I thought that was a common opinion...
Feb 26 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Lars Ivar Igesund wrote:
 Walter Bright wrote:
 
 
The match expressions are gone. Based on the feedback, people didn't want
D to adopt perl'ish notation or implicitly defined variables. Instead,
foreach statements now allow implicit typing of the key/value
declarations, and the if statement now can declare a variable for the
result (an adaptation of Ben Hinkle's idea).

I liked the idea (match expressions), just not the operator, and I thought that was a common opinion...

Me too (except I even liked the operator) :)
Feb 26 2006
parent reply Tom <Tom_member pathlink.com> writes:
In article <dts7qi$18b0$1 digitaldaemon.com>, Ivan Senji says...
Lars Ivar Igesund wrote:
 Walter Bright wrote:
 
 
The match expressions are gone. Based on the feedback, people didn't want
D to adopt perl'ish notation or implicitly defined variables. Instead,
foreach statements now allow implicit typing of the key/value
declarations, and the if statement now can declare a variable for the
result (an adaptation of Ben Hinkle's idea).

I liked the idea (match expressions), just not the operator, and I thought that was a common opinion...

Me too (except I even liked the operator) :)

There was a common opinion but on the opposed. I felt the same as Walter about match expressions in the NG. My own thought about match expressions is that they introduce TOO MUCH lib functionality (common only for certain types of apps), making D *very* overloaded (think about future writers of the compiler). The most of the people felt that introducing match expressions really introduces NO NEW functionality. Rather it just saves you the time of writing "import std.regexp;" (i guess). And also they introduced more complexity than needed and new bugs to fix. Match expressions was a luxury that D couldn't afford as D has many other *really-prior-and-crucial* things to work out if it want's to become 1.0. JMHO Tom;
Feb 26 2006
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Tom wrote:

 In article <dts7qi$18b0$1 digitaldaemon.com>, Ivan Senji says...
Lars Ivar Igesund wrote:
 Walter Bright wrote:
 
 
The match expressions are gone. Based on the feedback, people didn't
want D to adopt perl'ish notation or implicitly defined variables.
Instead, foreach statements now allow implicit typing of the key/value
declarations, and the if statement now can declare a variable for the
result (an adaptation of Ben Hinkle's idea).

I liked the idea (match expressions), just not the operator, and I thought that was a common opinion...

Me too (except I even liked the operator) :)

There was a common opinion but on the opposed. I felt the same as Walter about match expressions in the NG. My own thought about match expressions is that they introduce TOO MUCH lib functionality (common only for certain types of apps), making D *very* overloaded (think about future writers of the compiler). The most of the people felt that introducing match expressions really introduces NO NEW functionality. Rather it just saves you the time of writing "import std.regexp;" (i guess). And also they introduced more complexity than needed and new bugs to fix. Match expressions was a luxury that D couldn't afford as D has many other *really-prior-and-crucial* things to work out if it want's to become 1.0. JMHO Tom;

I think the "common opinion" was too coloured by the fact that we didn't really expect it to go away (but maybe change), thus many of those having positive feelings toward the match expressions didn't voice their opinion at all (at least I didn't). But I guess a vote would give a 50/50 result :)
Feb 26 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Lars Ivar Igesund wrote:
 Tom wrote:
 
 In article <dts7qi$18b0$1 digitaldaemon.com>, Ivan Senji says...
 Lars Ivar Igesund wrote:
 Walter Bright wrote:


 The match expressions are gone. Based on the feedback, people didn't
 want D to adopt perl'ish notation or implicitly defined variables.
 Instead, foreach statements now allow implicit typing of the key/value
 declarations, and the if statement now can declare a variable for the
 result (an adaptation of Ben Hinkle's idea).

I liked the idea (match expressions), just not the operator, and I thought that was a common opinion...


about match expressions in the NG. My own thought about match expressions is that they introduce TOO MUCH lib functionality (common only for certain types of apps), making D *very* overloaded (think about future writers of the compiler). The most of the people felt that introducing match expressions really introduces NO NEW functionality. Rather it just saves you the time of writing "import std.regexp;" (i guess). And also they introduced more complexity than needed and new bugs to fix. Match expressions was a luxury that D couldn't afford as D has many other *really-prior-and-crucial* things to work out if it want's to become 1.0. JMHO Tom;

I think the "common opinion" was too coloured by the fact that we didn't really expect it to go away (but maybe change), thus many of those having positive feelings toward the match expressions didn't voice their opinion at all (at least I didn't). But I guess a vote would give a 50/50 result :)

IMHO, match expressions are not a natural part of a language that claims to be for systems programming.
Feb 26 2006
prev sibling parent reply Tom <Tom_member pathlink.com> writes:
In article <dtse93$1fou$1 digitaldaemon.com>, Lars Ivar Igesund says...
Tom wrote:

 In article <dts7qi$18b0$1 digitaldaemon.com>, Ivan Senji says...
Lars Ivar Igesund wrote:
 Walter Bright wrote:
 
 
The match expressions are gone. Based on the feedback, people didn't
want D to adopt perl'ish notation or implicitly defined variables.
Instead, foreach statements now allow implicit typing of the key/value
declarations, and the if statement now can declare a variable for the
result (an adaptation of Ben Hinkle's idea).

I liked the idea (match expressions), just not the operator, and I thought that was a common opinion...

Me too (except I even liked the operator) :)

There was a common opinion but on the opposed. I felt the same as Walter about match expressions in the NG. My own thought about match expressions is that they introduce TOO MUCH lib functionality (common only for certain types of apps), making D *very* overloaded (think about future writers of the compiler). The most of the people felt that introducing match expressions really introduces NO NEW functionality. Rather it just saves you the time of writing "import std.regexp;" (i guess). And also they introduced more complexity than needed and new bugs to fix. Match expressions was a luxury that D couldn't afford as D has many other *really-prior-and-crucial* things to work out if it want's to become 1.0. JMHO Tom;

I think the "common opinion" was too coloured by the fact that we didn't really expect it to go away (but maybe change), thus many of those having positive feelings toward the match expressions didn't voice their opinion at all (at least I didn't). But I guess a vote would give a 50/50 result :)

Maybe (don't think so) but we'll have to see it to believe it. ;-) Tom;
Feb 26 2006
parent Dave <Dave_member pathlink.com> writes:
In article <dtsge2$1i5t$1 digitaldaemon.com>, Tom says...
In article <dtse93$1fou$1 digitaldaemon.com>, Lars Ivar Igesund says...
Tom wrote:

 In article <dts7qi$18b0$1 digitaldaemon.com>, Ivan Senji says...
Lars Ivar Igesund wrote:
 Walter Bright wrote:
 
 
The match expressions are gone. Based on the feedback, people didn't
want D to adopt perl'ish notation or implicitly defined variables.
Instead, foreach statements now allow implicit typing of the key/value
declarations, and the if statement now can declare a variable for the
result (an adaptation of Ben Hinkle's idea).

I liked the idea (match expressions), just not the operator, and I thought that was a common opinion...

Me too (except I even liked the operator) :)

There was a common opinion but on the opposed. I felt the same as Walter about match expressions in the NG. My own thought about match expressions is that they introduce TOO MUCH lib functionality (common only for certain types of apps), making D *very* overloaded (think about future writers of the compiler). The most of the people felt that introducing match expressions really introduces NO NEW functionality. Rather it just saves you the time of writing "import std.regexp;" (i guess). And also they introduced more complexity than needed and new bugs to fix. Match expressions was a luxury that D couldn't afford as D has many other *really-prior-and-crucial* things to work out if it want's to become 1.0. JMHO Tom;

I think the "common opinion" was too coloured by the fact that we didn't really expect it to go away (but maybe change), thus many of those having positive feelings toward the match expressions didn't voice their opinion at all (at least I didn't). But I guess a vote would give a 50/50 result :)

Maybe (don't think so) but we'll have to see it to believe it. ;-) Tom;

IMHO, the vote would be about 70 - 30 for the built-in's, especially with the addition of 'if statement result declarations' that would get rid of the implicit variables. Since AFAIK they don't complicate the compiler that much, they don't have any overhead if they aren't used and don't prevent the direct use of a regex library, I don't see any downside of making them built-in. - Dave
Feb 26 2006
prev sibling next sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <dts47r$14c0$1 digitaldaemon.com>, Lars Ivar Igesund says...
Walter Bright wrote:

 The match expressions are gone. Based on the feedback, people didn't want
 D to adopt perl'ish notation or implicitly defined variables. Instead,
 foreach statements now allow implicit typing of the key/value
 declarations, and the if statement now can declare a variable for the
 result (an adaptation of Ben Hinkle's idea).

I liked the idea (match expressions), just not the operator, and I thought that was a common opinion...

So did I (but the operators didn't bother me). I was surprised to see the 'built-in' behaviour removed. From my understanding, it wasn't terribly complicated to implement and there wasn't any overhead unless it was used. There really wasn't any 'perl'ish notation' to speak of, and the recent addition of if statement result variables would have taken care of the implicitly defined variable issue. I think it was a mistake to remove the built-in's. Now I bet they're gone for good. Arrrgh. I think D would better appeal to a large segment of developers (using scripting languages like Perl) with the built-in regex match functionality. IIRC, most of the posts liked the built-in idea but took issue with a few of the details. We've gone from talk about how the compiler can optimize matching behaviour to removing the built-in's entirely. I don't get it.. - Dave
Feb 26 2006
parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
In article <dtsjs6$1lp0$1 digitaldaemon.com>, Dave says...
In article <dts47r$14c0$1 digitaldaemon.com>, Lars Ivar Igesund says...
Walter Bright wrote:

 The match expressions are gone. Based on the feedback, people didn't want
 D to adopt perl'ish notation or implicitly defined variables. Instead,
 foreach statements now allow implicit typing of the key/value
 declarations, and the if statement now can declare a variable for the
 result (an adaptation of Ben Hinkle's idea).

I liked the idea (match expressions), just not the operator, and I thought that was a common opinion...

So did I (but the operators didn't bother me). I was surprised to see the 'built-in' behaviour removed. From my understanding, it wasn't terribly complicated to implement and there wasn't any overhead unless it was used. There really wasn't any 'perl'ish notation' to speak of, and the recent addition of if statement result variables would have taken care of the implicitly defined variable issue. I think it was a mistake to remove the built-in's. Now I bet they're gone for good. Arrrgh. I think D would better appeal to a large segment of developers (using scripting languages like Perl) with the built-in regex match functionality. IIRC, most of the posts liked the built-in idea but took issue with a few of the details. We've gone from talk about how the compiler can optimize matching behaviour to removing the built-in's entirely. I don't get it.. - Dave

I think the addition and than removal was pretty odd.. I was just about to rewrite some code using the match operator - but I am glad I diddn't. But you know - as much as we all demand features and get mad when they aren't included, it was nice to see a feature get included. But now it gets taken away so quickly, I don't know what will be taken out next.. :) Please don't remove dynamic arrays walter! Just kidding - we all love you! Thanks, Trevor Parscal
Feb 26 2006
next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
Trevor Parscal wrote:
 In article <dtsjs6$1lp0$1 digitaldaemon.com>, Dave says...
 
In article <dts47r$14c0$1 digitaldaemon.com>, Lars Ivar Igesund says...

Walter Bright wrote:


The match expressions are gone. Based on the feedback, people didn't want
D to adopt perl'ish notation or implicitly defined variables. Instead,
foreach statements now allow implicit typing of the key/value
declarations, and the if statement now can declare a variable for the
result (an adaptation of Ben Hinkle's idea).

I liked the idea (match expressions), just not the operator, and I thought that was a common opinion...

So did I (but the operators didn't bother me). I was surprised to see the 'built-in' behaviour removed. From my understanding, it wasn't terribly complicated to implement and there wasn't any overhead unless it was used. There really wasn't any 'perl'ish notation' to speak of, and the recent addition of if statement result variables would have taken care of the implicitly defined variable issue. I think it was a mistake to remove the built-in's. Now I bet they're gone for good. Arrrgh. I think D would better appeal to a large segment of developers (using scripting languages like Perl) with the built-in regex match functionality. IIRC, most of the posts liked the built-in idea but took issue with a few of the details. We've gone from talk about how the compiler can optimize matching behaviour to removing the built-in's entirely. I don't get it.. - Dave

I think the addition and than removal was pretty odd.. I was just about to rewrite some code using the match operator - but I am glad I diddn't. But you know - as much as we all demand features and get mad when they aren't included, it was nice to see a feature get included. But now it gets taken away so quickly, I don't know what will be taken out next.. :) Please don't remove dynamic arrays walter! Just kidding - we all love you! Thanks, Trevor Parscal

Why is this move (taking out the built-in behavior) so seemingly unexpected to everyone? Walter outright said "Don't write production code with this feature." -- Regards, James Dunne
Feb 26 2006
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
James Dunne wrote:

 Trevor Parscal wrote:
 In article <dtsjs6$1lp0$1 digitaldaemon.com>, Dave says...
 
In article <dts47r$14c0$1 digitaldaemon.com>, Lars Ivar Igesund says...

Walter Bright wrote:


The match expressions are gone. Based on the feedback, people didn't
want D to adopt perl'ish notation or implicitly defined variables.
Instead, foreach statements now allow implicit typing of the key/value
declarations, and the if statement now can declare a variable for the
result (an adaptation of Ben Hinkle's idea).

I liked the idea (match expressions), just not the operator, and I thought that was a common opinion...

So did I (but the operators didn't bother me). I was surprised to see the 'built-in' behaviour removed. From my understanding, it wasn't terribly complicated to implement and there wasn't any overhead unless it was used. There really wasn't any 'perl'ish notation' to speak of, and the recent addition of if statement result variables would have taken care of the implicitly defined variable issue. I think it was a mistake to remove the built-in's. Now I bet they're gone for good. Arrrgh. I think D would better appeal to a large segment of developers (using scripting languages like Perl) with the built-in regex match functionality. IIRC, most of the posts liked the built-in idea but took issue with a few of the details. We've gone from talk about how the compiler can optimize matching behaviour to removing the built-in's entirely. I don't get it.. - Dave

I think the addition and than removal was pretty odd.. I was just about to rewrite some code using the match operator - but I am glad I diddn't. But you know - as much as we all demand features and get mad when they aren't included, it was nice to see a feature get included. But now it gets taken away so quickly, I don't know what will be taken out next.. :) Please don't remove dynamic arrays walter! Just kidding - we all love you! Thanks, Trevor Parscal

Why is this move (taking out the built-in behavior) so seemingly unexpected to everyone? Walter outright said "Don't write production code with this feature."

You are of course correct in this, but it in my (quite so erratic at times) mind, this meant that the syntax probably would be changed, not removed altoghether. Also, I don't really think the D as Script feature makes much sense without some additional regexy sugar, even if it is still quite usable of course.
Feb 26 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message 
news:dtso8j$1r01$1 digitaldaemon.com...
 You are of course correct in this, but it in my (quite so erratic at 
 times)
 mind, this meant that the syntax probably would be changed, not removed
 altoghether. Also, I don't really think the D as Script feature makes much
 sense without some additional regexy sugar, even if it is still quite
 usable of course.

It's still there in the form: if (m; search("string", "pattern")) ... do something with m.match(0) ... as opposed to: if ("pattern" ~~ "search") ... do something with _match.match(0) ... There isn't much sugar to the latter over the former, and it has the disadvantage of implicit declarations, which in general are a bad idea.
Feb 26 2006
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Trevor Parscal" <Trevor_member pathlink.com> wrote in message 
news:dtsl91$1ncs$1 digitaldaemon.com...
 I think the addition and than removal was pretty odd.. I was just about to
 rewrite some code using the match operator - but I am glad I diddn't.

 But you know - as much as we all demand features and get mad when they 
 aren't
 included, it was nice to see a feature get included. But now it gets taken 
 away
 so quickly, I don't know what will be taken out next.. :)

I wouldn't have removed it, but adding the declarations to the if statement, and the implicit typing to the foreach, made the match expression's incremental convenience pretty minor. Lest D become a bag of cruft, new operators need to offer a *big* improvement in convenience.
 Please don't remove dynamic arrays walter!

Fat chance of that!
Feb 26 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message 
news:dts47r$14c0$1 digitaldaemon.com...
 I liked the idea (match expressions), just not the operator, and I thought
 that was a common opinion...

if ("regex" ~~ "string") _match. ... The equivalent functionality can now be done with: if (m; search("string", "regex")) m. ...
Feb 26 2006
next sibling parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
Walter Bright wrote:
 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message 
 news:dts47r$14c0$1 digitaldaemon.com...
 I liked the idea (match expressions), just not the operator, and I thought
 that was a common opinion...

if ("regex" ~~ "string") _match. ... The equivalent functionality can now be done with: if (m; search("string", "regex")) m. ...

Why not do like this instead? if (m;"regex" ~~ "string") m. ... That would get rid of the implicit declaration of _match and just like usual with statements the result of ~~ could bee ignored.
Feb 26 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Johan Granberg" <lijat.meREM OVEgmail.com> wrote in message 
news:dtsu0h$21ct$1 digitaldaemon.com...
 Why not do like this instead?

 if (m;"regex" ~~ "string")
 m. ...

 That would get rid of the implicit declaration of _match and just like 
 usual with statements the result of ~~ could bee ignored.

Because it doesn't offer enough utility over the function version to justify it.
Feb 26 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Mon, 27 Feb 2006 04:58:21 +1100, Walter Bright  
<newshound digitalmars.com> wrote:

 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message
 news:dts47r$14c0$1 digitaldaemon.com...
 I liked the idea (match expressions), just not the operator, and I  
 thought
 that was a common opinion...

if ("regex" ~~ "string") _match. ... The equivalent functionality can now be done with: if (m; search("string", "regex")) m. ...

I don't think that is quite correct. This program failed to compile .... void main() { if (m; search("string", "regex")) {} } I got the messages ... test2.d(3): undefined identifier search test2.d(3): function expected before (), not search of type int It turns out that "import std.regexp;" is now required. -- Derek Parnell Melbourne, Australia
Feb 26 2006
next sibling parent reply Tom <Tom_member pathlink.com> writes:
In article <op.s5lhaxyb6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell says...
On Mon, 27 Feb 2006 04:58:21 +1100, Walter Bright  
<newshound digitalmars.com> wrote:

 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message
 news:dts47r$14c0$1 digitaldaemon.com...
 I liked the idea (match expressions), just not the operator, and I  
 thought
 that was a common opinion...

if ("regex" ~~ "string") _match. ... The equivalent functionality can now be done with: if (m; search("string", "regex")) m. ...

I don't think that is quite correct. This program failed to compile .... void main() { if (m; search("string", "regex")) {} } I got the messages ... test2.d(3): undefined identifier search test2.d(3): function expected before (), not search of type int It turns out that "import std.regexp;" is now required.

This was pretty obvious IMO, don't you think so? :) I mean, if the feature was removed, of course, you would require 'std.regexp' imported again. I think Walter omitted it because of that. Tom;
Feb 26 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Mon, 27 Feb 2006 06:46:41 +1100, Tom <Tom_member pathlink.com> wrote:

 In article <op.s5lhaxyb6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell  
 says...
 On Mon, 27 Feb 2006 04:58:21 +1100, Walter Bright
 <newshound digitalmars.com> wrote:

 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message
 news:dts47r$14c0$1 digitaldaemon.com...
 I liked the idea (match expressions), just not the operator, and I
 thought
 that was a common opinion...

if ("regex" ~~ "string") _match. ... The equivalent functionality can now be done with: if (m; search("string", "regex")) m. ...

I don't think that is quite correct. This program failed to compile .... void main() { if (m; search("string", "regex")) {} } I got the messages ... test2.d(3): undefined identifier search test2.d(3): function expected before (), not search of type int It turns out that "import std.regexp;" is now required.

This was pretty obvious IMO, don't you think so? :) I mean, if the feature was removed, of course, you would require 'std.regexp' imported again. I think Walter omitted it because of that.

Of course it was obvious; that was my point. Walter had written that "if ("regex" ~~ "string")" was functionally equivalent to "if (m; search("string", "regex"))" and while that is true, it gives the impression that this was the *only* change to the new D. I just wanted to point out that the implicit importing of std.regexp was also removed. -- Derek Parnell Melbourne, Australia
Feb 26 2006
parent Tom <Tom_member pathlink.com> writes:
In article <op.s5lmdqep6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell says...
On Mon, 27 Feb 2006 06:46:41 +1100, Tom <Tom_member pathlink.com> wrote:

 In article <op.s5lhaxyb6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell  
 says...
 On Mon, 27 Feb 2006 04:58:21 +1100, Walter Bright
 <newshound digitalmars.com> wrote:

 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message
 news:dts47r$14c0$1 digitaldaemon.com...
 I liked the idea (match expressions), just not the operator, and I
 thought
 that was a common opinion...

if ("regex" ~~ "string") _match. ... The equivalent functionality can now be done with: if (m; search("string", "regex")) m. ...

I don't think that is quite correct. This program failed to compile .... void main() { if (m; search("string", "regex")) {} } I got the messages ... test2.d(3): undefined identifier search test2.d(3): function expected before (), not search of type int It turns out that "import std.regexp;" is now required.

This was pretty obvious IMO, don't you think so? :) I mean, if the feature was removed, of course, you would require 'std.regexp' imported again. I think Walter omitted it because of that.

Of course it was obvious; that was my point. Walter had written that "if ("regex" ~~ "string")" was functionally equivalent to "if (m; search("string", "regex"))" and while that is true, it gives the impression that this was the *only* change to the new D. I just wanted to point out that the implicit importing of std.regexp was also removed.

Ok, I forgive you :) :P Now seriously, I see your point. Regards, Tom;
Feb 26 2006
prev sibling next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:op.s5lhaxyb6b8z09 ginger.vic.bigpond.net.au...
 It turns out that "import std.regexp;" is now required.

That's right.
Feb 26 2006
prev sibling parent Dave <Dave_member pathlink.com> writes:
In article <op.s5lhaxyb6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell says...
On Mon, 27 Feb 2006 04:58:21 +1100, Walter Bright  
<newshound digitalmars.com> wrote:

 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message
 news:dts47r$14c0$1 digitaldaemon.com...
 I liked the idea (match expressions), just not the operator, and I  
 thought
 that was a common opinion...

if ("regex" ~~ "string") _match. ... The equivalent functionality can now be done with: if (m; search("string", "regex")) m. ...

I don't think that is quite correct. This program failed to compile .... void main() { if (m; search("string", "regex")) {} } I got the messages ... test2.d(3): undefined identifier search test2.d(3): function expected before (), not search of type int It turns out that "import std.regexp;" is now required. -- Derek Parnell Melbourne, Australia

Maybe a good compromise would be to use a built-in "proxy" for search() and RegExp (along the same lines as '~~' was originally implemented)? Then there would be no "perl'ish" syntax, no added operators, no overhead and the same convenience to doing regex matching. One problem I see with the new v0.148 regex stuff is that different search functions (and syntax for them) are used for if() and foreach(), and they aren't interchangable. That's going to be confusing for newbies and feels kludgy to me - can't the two functions be combined somehow? - Dave
Feb 26 2006
prev sibling next sibling parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dtr2ff$2vqr$3 digitaldaemon.com...
 The match expressions are gone. Based on the feedback, people didn't want 
 D to adopt perl'ish notation or implicitly defined variables. Instead, 
 foreach statements now allow implicit typing of the key/value 
 declarations, and the if statement now can declare a variable for the 
 result (an adaptation of Ben Hinkle's idea).

Too bad you didn't create a separate thread for the new if statement. What was wrong with the C++ construction: if (int a = getSome()) {...} ? L.
Feb 27 2006
parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
 Too bad you didn't create a separate thread for the new if statement. What 
 was wrong with the C++ construction:

Nevermind. I've found the thread already...
Feb 27 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <dtr2ff$2vqr$3 digitaldaemon.com>, Walter Bright says...
if statement now can declare a variable for the result (an adaptation of Ben 
Hinkle's idea). 

I haven't seen this brought up yet, so if it has my apologies. The if(valptr; (key in AA)) syntax also nicely improves on how 'in' is used to avoid double lookups IMO. Still uses a pointer, but it is alot better. old way: int* p = (key in AA); if(p) (*p)++; else AA[key] = 1; new: if(p; key in AA) (*p)++; else AA[key] = 1; - Dave
Mar 02 2006
next sibling parent reply Chris Sauls <ibisbasenji gmail.com> writes:
Dave wrote:
 In article <dtr2ff$2vqr$3 digitaldaemon.com>, Walter Bright says...
 
if statement now can declare a variable for the result (an adaptation of Ben 
Hinkle's idea). 

The if(valptr; (key in AA)) syntax also nicely improves on how 'in' is used to avoid double lookups IMO. Still uses a pointer, but it is alot better. old way: int* p = (key in AA); if(p) (*p)++; else AA[key] = 1; new: if(p; key in AA) (*p)++; else AA[key] = 1; - Dave

I hadn't even thought of that yet... and I love it! A server project of mine uses the 'in' operator quite a bit, and I've always been annoyed with predeclaring variables and whatnot. Now I won't have that issue, so long as Walter does the Right Thing (TM) and leaves this in. -- Chris Nicholson-Sauls
Mar 02 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Chris Sauls" <ibisbasenji gmail.com> wrote in message 
news:du8kgk$tem$1 digitaldaemon.com...
 I hadn't even thought of that yet...  and I love it!  A server project of 
 mine uses the 'in' operator quite a bit, and I've always been annoyed with 
 predeclaring variables and whatnot.  Now I won't have that issue, so long 
 as Walter does the Right Thing (TM) and leaves this in.

It'll stay in, but it'll be in the form: if (auto p = key in AA) as just about everyone seemed to prefer that syntax.
Mar 03 2006
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:
 "Chris Sauls" <ibisbasenji gmail.com> wrote in message 
 news:du8kgk$tem$1 digitaldaemon.com...
 
I hadn't even thought of that yet...  and I love it!  A server project of 
mine uses the 'in' operator quite a bit, and I've always been annoyed with 
predeclaring variables and whatnot.  Now I won't have that issue, so long 
as Walter does the Right Thing (TM) and leaves this in.

It'll stay in, but it'll be in the form: if (auto p = key in AA) as just about everyone seemed to prefer that syntax.

Will this work: if( auto a = something() && auto b = something()) a more general solution of declaring/initializing variables by parts of expressions? (auto a1 = x*y-z) * (1 - (auto a2 = sin(x+y)))? That would be a nice feature, but maybe too complicated and not that much used?
Mar 04 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
news:dubrop$118j$1 digitaldaemon.com...
 Will this work:

 if( auto a = something() && auto b = something())

 a more general solution of declaring/initializing variables by parts of 
 expressions?

No, it won't work. Embedding declarations inside expressions leads to all sorts of problems, not the least of which is what happens in this scenario: if (auto a = foo() || auto b = bar()) { a + b; // is b declared or not? }
Mar 06 2006
next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:
 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
 news:dubrop$118j$1 digitaldaemon.com...
 
Will this work:

if( auto a = something() && auto b = something())

a more general solution of declaring/initializing variables by parts of 
expressions?

No, it won't work. Embedding declarations inside expressions leads to all sorts of problems, not the least of which is what happens in this scenario:

OK, I get it.
 
     if (auto a = foo() || auto b = bar())
     {
             a + b;        // is b declared or not?
     } 
 
 

Mar 06 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Brad Roberts wrote:
 
    For all variables declared in an if expression, they will be default 
 initialized if their initializing expression is not executed due to short 
 circuit evaluation.

I had the same thought. But how much value is there in offering this feature? Since D defaults to trap values when possible, the user should typically check all values that may have been default initialized before using them, and this seems to reduce the utility of this syntax. Though I suppose this doesn't change the fact that there is a simple, valid solution to the problem, which is the point you were trying to make. Sean
Mar 06 2006
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Brad Roberts" <braddr puremagic.com> wrote in message 
news:Pine.LNX.4.64.0603061143490.30259 bellevue.puremagic.com...
 Easy enough to define the behavior.

I know. But if there isn't an obvious and intuitive behavior to define, then one is picking something arbitrary. For example, the classic conundrum is: "12" + 6 Does that evaluate to "126" or 18? One can easilly define the behavior, but which one, and what will programmers expect it to be? With that expression, there really are only wrong answers, and so the only solution is to make it illegal. For: if (auto a = foo() || auto b = bar()) { a + b; // is b declared or not? } one could as sensibly define that b is only valid in the conditional subexpression in which it appears, as in: if (auto a = foo() || (auto b = bar(), b + 1)) // ok, b valid in the b+1 expression { a + b; // error, b undefined here } Faced with two equally valid but incompatible definitions, I think the best course of action is to make it illegal, especially since there doesn't seem to be much utility in such a feature anyway.
Mar 08 2006
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
On Mon, 6 Mar 2006, Walter Bright wrote:

 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
 news:dubrop$118j$1 digitaldaemon.com...
 Will this work:

 if( auto a = something() && auto b = something())

 a more general solution of declaring/initializing variables by parts of 
 expressions?

No, it won't work. Embedding declarations inside expressions leads to all sorts of problems, not the least of which is what happens in this scenario: if (auto a = foo() || auto b = bar()) { a + b; // is b declared or not? }

Easy enough to define the behavior. I'm not sure what an appropriate term is for variables declared like this, so insert something appropriate below. Something like this would work reasonably well, probably: For all variables declared in an if expression, they will be default initialized if their initializing expression is not executed due to short circuit evaluation. So.. if (auto /* int */ res1 = someIntegerExpression() || auto /* int */ res2 = someOtherIntegerExpression()) { return res1 + res2; } The results of that become well defined. What would be potentially problematic is if return types are ever added to function overloading / resolution. But I won't get into my opinions on that or on implicit typing as it's ornthogonal to this topic. Later, Brad
Mar 06 2006