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

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

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.

"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. ...

"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!

"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.

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

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.

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

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;