It looks like std.regexp was marked in its documentation as deprecated in 2.053. It was not actually deprecated (the deprecation modifier is missing), but if it has indeed been deprecated (and std.regex has been around for a while, so it's not exactly a surprise), then it needs to actually be deprecated, and the rest of Phobos needs to be using std.regex instead. I can easily deprecate the function (after all, all you have to do is add deprecated: near the top of the file), but since I've never used either of the regex modules, I'm ill-suited to convert the rest of Phobos to use std.regex. So, I'd appreciate it if someone who is actually familiar with the two modules would convert the rest of Phobos to use std.regex sometime prior to the next release, and then we can actually deprecate std.regexp. Worse comes to worst, I can take a crack at it, but it would be much faster if someone who's familiar with the regex modules did it.

Now, we may actually want to change std.regexp to "scheduled for deprecation" rather than deprecated simply because there are other functions in Phobos which take stuff from std.regexp but not std.regex (such as the version of std.file.listdir which takes a RegExp) have not yet been scheduled for deprecation, let alone deprecated, but regardless, we need to change the rest of Phobos to use std.regex or we won't be able to actually deprecate and remove std.regexp (well, I suppose that we _could_ deprecate it as-is, but it seems to me to be a bad idea to deprecate something when Phobos is still using it in its API elsewhere).

- Jonathan M Davis

On 6/5/2011 12:52 AM, Jonathan M Davis wrote:
> It looks like std.regexp was marked in its documentation as deprecated in 2.053. It was not actually deprecated (the deprecation modifier is missing), but if it has indeed been deprecated (and std.regex has been around for a while, so it's not exactly a surprise), then it needs to actually be deprecated, and the rest of Phobos needs to be using std.regex instead. I can easily deprecate the function (after all, all you have to do is add deprecated: near the top of the file), but since I've never used either of the regex modules, I'm ill-suited to convert the rest of Phobos to use std.regex. So, I'd appreciate it if someone who is actually familiar with the two modules would convert the rest of Phobos to use std.regex sometime prior to the next release, and then we can actually deprecate std.regexp. Worse comes to worst, I can take a crack at it, but it would be much faster if someone who's familiar with the regex modules did it.
> 
> Now, we may actually want to change std.regexp to "scheduled for deprecation" rather than deprecated simply because there are other functions in Phobos which take stuff from std.regexp but not std.regex (such as the version of std.file.listdir which takes a RegExp) have not yet been scheduled for deprecation, let alone deprecated, but regardless, we need to change the rest of Phobos to use std.regex or we won't be able to actually deprecate and remove std.regexp (well, I suppose that we _could_ deprecate it as-is, but it seems to me to be a bad idea to deprecate something when Phobos is still using it in its API elsewhere).
> 
> - Jonathan M Davis

It was marked deprecated once (check out the blame history of the file), but that was reverted since commonly used modules still use it.  The effect would be that essentially every app would need to be compiled with -d, which is hardly useful.  Until phobos doesn't use it, no real deprecation can actually occur.

On 2011-06-05 00:56, Brad Roberts wrote:
> On 6/5/2011 12:52 AM, Jonathan M Davis wrote:
> > It looks like std.regexp was marked in its documentation as deprecated in 2.053. It was not actually deprecated (the deprecation modifier is missing), but if it has indeed been deprecated (and std.regex has been around for a while, so it's not exactly a surprise), then it needs to actually be deprecated, and the rest of Phobos needs to be using std.regex instead. I can easily deprecate the function (after all, all you have to do is add deprecated: near the top of the file), but since I've never used either of the regex modules, I'm ill-suited to convert the rest of Phobos to use std.regex. So, I'd appreciate it if someone who is actually familiar with the two modules would convert the rest of Phobos to use std.regex sometime prior to the next release, and then we can actually deprecate std.regexp. Worse comes to worst, I can take a crack at it, but it would be much faster if someone who's familiar with the regex modules did it.
> > 
> > Now, we may actually want to change std.regexp to "scheduled for deprecation" rather than deprecated simply because there are other functions in Phobos which take stuff from std.regexp but not std.regex (such as the version of std.file.listdir which takes a RegExp) have not yet been scheduled for deprecation, let alone deprecated, but regardless, we need to change the rest of Phobos to use std.regex or we won't be able to actually deprecate and remove std.regexp (well, I suppose that we _could_ deprecate it as-is, but it seems to me to be a bad idea to deprecate something when Phobos is still using it in its API elsewhere).
> > 
> > - Jonathan M Davis
> 
> It was marked deprecated once (check out the blame history of the file), but that was reverted since commonly used modules still use it.  The effect would be that essentially every app would need to be compiled with -d, which is hardly useful.  Until phobos doesn't use it, no real deprecation can actually occur.

That's essentially my point. Someone needs to convert the rest of Phobos so that it uses std.regex instead of std.regexp before we can properly deprecate std.regexp (and given all of the stuff in Phobos which still uses std.regexp, we should probably make it so that std.regexp is _scheduled_ for deprecation rather than deprecated, but the changes still need to be made). Simply marking std.regexp as deprecated in its documentation isn't enough. I'm raising the issue so that someone who is actually familiar with std.regexp and std.regex can do the conversion.

- Jonathan M Davis

On 05.06.2011 12:13, Jonathan M Davis wrote:
> On 2011-06-05 00:56, Brad Roberts wrote:
>> On 6/5/2011 12:52 AM, Jonathan M Davis wrote:
>>> It looks like std.regexp was marked in its documentation as deprecated in 2.053. It was not actually deprecated (the deprecation modifier is missing), but if it has indeed been deprecated (and std.regex has been around for a while, so it's not exactly a surprise), then it needs to actually be deprecated, and the rest of Phobos needs to be using std.regex instead. I can easily deprecate the function (after all, all you have to do is add deprecated: near the top of the file), but since I've never used either of the regex modules, I'm ill-suited to convert the rest of Phobos to use std.regex. So, I'd appreciate it if someone who is actually familiar with the two modules would convert the rest of Phobos to use std.regex sometime prior to the next release, and then we can actually deprecate std.regexp. Worse comes to worst, I can take a crack at it, but it would be much faster if someone who's familiar with the regex modules did it.
>>>
>>> Now, we may actually want to change std.regexp to "scheduled for deprecation" rather than deprecated simply because there are other functions in Phobos which take stuff from std.regexp but not std.regex (such as the version of std.file.listdir which takes a RegExp) have not yet been scheduled for deprecation, let alone deprecated, but regardless, we need to change the rest of Phobos to use std.regex or we won't be able to actually deprecate and remove std.regexp (well, I suppose that we _could_ deprecate it as-is, but it seems to me to be a bad idea to deprecate something when Phobos is still using it in its API elsewhere).
>>>
>>> - Jonathan M Davis
>> It was marked deprecated once (check out the blame history of the file), but that was reverted since commonly used modules still use it.  The effect would be that essentially every app would need to be compiled with -d, which is hardly useful.  Until phobos doesn't use it, no real deprecation can actually occur.
> That's essentially my point. Someone needs to convert the rest of Phobos so that it uses std.regex instead of std.regexp before we can properly deprecate std.regexp (and given all of the stuff in Phobos which still uses std.regexp, we should probably make it so that std.regexp is _scheduled_ for deprecation rather than deprecated, but the changes still need to be made). Simply marking std.regexp as deprecated in its documentation isn't enough. I'm raising the issue so that someone who is actually familiar with std.regexp and std.regex can do the conversion.
>
Looks like I'm the one best suited for this, since I have extensive
experience with both modules and their internals.
In fact, I'm doing GSOC project aimed at enhancing current std.regex,
basically replacing implementation and extending interface quite a bit.
Still changes going to be backwards compatible, so it's about time to
switch all phobos to std.regex.
I'll make a pull request soon.

-- 
Dmitry Olshansky

On 06/05/2011 11:38 AM, Dmitry Olshansky wrote:
> Looks like I'm the one best suited for this, since I have extensive
> experience with both modules and their internals.
> In fact, I'm doing GSOC project aimed at enhancing current std.regex,
> basically replacing implementation and extending interface quite a bit.
> Still changes going to be backwards compatible, so it's about time to
> switch all phobos to std.regex.
> I'll make a pull request soon.

Terrific. Thanks Dmitry!

Andrei

On 2011-06-05 09:38, Dmitry Olshansky wrote:
> On 05.06.2011 12:13, Jonathan M Davis wrote:
> > On 2011-06-05 00:56, Brad Roberts wrote:
> >> On 6/5/2011 12:52 AM, Jonathan M Davis wrote:
> >>> It looks like std.regexp was marked in its documentation as deprecated in 2.053. It was not actually deprecated (the deprecation modifier is missing), but if it has indeed been deprecated (and std.regex has been around for a while, so it's not exactly a surprise), then it needs to actually be deprecated, and the rest of Phobos needs to be using std.regex instead. I can easily deprecate the function (after all, all you have to do is add deprecated: near the top of the file), but since I've never used either of the regex modules, I'm ill-suited to convert the rest of Phobos to use std.regex. So, I'd appreciate it if someone who is actually familiar with the two modules would convert the rest of Phobos to use std.regex sometime prior to the next release, and then we can actually deprecate std.regexp. Worse comes to worst, I can take a crack at it, but it would be much faster if someone who's familiar with the regex modules did it.
> >>> 
> >>> Now, we may actually want to change std.regexp to "scheduled for deprecation" rather than deprecated simply because there are other functions in Phobos which take stuff from std.regexp but not std.regex (such as the version of std.file.listdir which takes a RegExp) have not yet been scheduled for deprecation, let alone deprecated, but regardless, we need to change the rest of Phobos to use std.regex or we won't be able to actually deprecate and remove std.regexp (well, I suppose that we _could_ deprecate it as-is, but it seems to me to be a bad idea to deprecate something when Phobos is still using it in its API elsewhere).
> >>> 
> >>> - Jonathan M Davis
> >> 
> >> It was marked deprecated once (check out the blame history of the file), but that was reverted since commonly used modules still use it.  The effect would be that essentially every app would need to be compiled with -d, which is hardly useful.  Until phobos doesn't use it, no real deprecation can actually occur.
> > 
> > That's essentially my point. Someone needs to convert the rest of Phobos so that it uses std.regex instead of std.regexp before we can properly deprecate std.regexp (and given all of the stuff in Phobos which still uses std.regexp, we should probably make it so that std.regexp is _scheduled_ for deprecation rather than deprecated, but the changes still need to be made). Simply marking std.regexp as deprecated in its documentation isn't enough. I'm raising the issue so that someone who is actually familiar with std.regexp and std.regex can do the conversion.
> 
> Looks like I'm the one best suited for this, since I have extensive
> experience with both modules and their internals.
> In fact, I'm doing GSOC project aimed at enhancing current std.regex,
> basically replacing implementation and extending interface quite a bit.
> Still changes going to be backwards compatible, so it's about time to
> switch all phobos to std.regex.
> I'll make a pull request soon.

Thanks! Remember that where possible, functions in Phobos' public API which would be affected by the change should have the old version kept temporarily as "scheduled for deprecation" in order to give people some time to convert over rather than immediately breaking their code. And if the old function is a template, then a pragma warning about the the change should be put inside it. You can look at what std.file is currently doing with functions scheduled for deprecation for examples. Don't worry too much about the exact messages. I can go and adjust them later. Just mark them as scheduled for deprecation.

The current plan is that anything which is deprecated should be scheduled for deprecation for about 6 months, deprecated for 6 months, and then removed. But std.regex has been around long enough that I suspect that we can accelerate that process a bit in this case.

In any case, thank you for taking the time to convert over Phobos to std.regex. Then we can finally move towards removing std.regexp.

- Jonathan M Davis

On 06.06.2011 3:20, Jonathan M Davis wrote:
> On 2011-06-05 09:38, Dmitry Olshansky wrote:
>> On 05.06.2011 12:13, Jonathan M Davis wrote:
>>> On 2011-06-05 00:56, Brad Roberts wrote:
>>>> On 6/5/2011 12:52 AM, Jonathan M Davis wrote:
>>>>> It looks like std.regexp was marked in its documentation as deprecated in 2.053. It was not actually deprecated (the deprecation modifier is missing), but if it has indeed been deprecated (and std.regex has been around for a while, so it's not exactly a surprise), then it needs to actually be deprecated, and the rest of Phobos needs to be using std.regex instead. I can easily deprecate the function (after all, all you have to do is add deprecated: near the top of the file), but since I've never used either of the regex modules, I'm ill-suited to convert the rest of Phobos to use std.regex. So, I'd appreciate it if someone who is actually familiar with the two modules would convert the rest of Phobos to use std.regex sometime prior to the next release, and then we can actually deprecate std.regexp. Worse comes to worst, I can take a crack at it, but it would be much faster if someone who's familiar with the regex modules did it.
>>>>>
>>>>> Now, we may actually want to change std.regexp to "scheduled for deprecation" rather than deprecated simply because there are other functions in Phobos which take stuff from std.regexp but not std.regex (such as the version of std.file.listdir which takes a RegExp) have not yet been scheduled for deprecation, let alone deprecated, but regardless, we need to change the rest of Phobos to use std.regex or we won't be able to actually deprecate and remove std.regexp (well, I suppose that we _could_ deprecate it as-is, but it seems to me to be a bad idea to deprecate something when Phobos is still using it in its API elsewhere).
>>>>>
>>>>> - Jonathan M Davis
>>>> It was marked deprecated once (check out the blame history of the file), but that was reverted since commonly used modules still use it.  The effect would be that essentially every app would need to be compiled with -d, which is hardly useful.  Until phobos doesn't use it, no real deprecation can actually occur.
>>> That's essentially my point. Someone needs to convert the rest of Phobos so that it uses std.regex instead of std.regexp before we can properly deprecate std.regexp (and given all of the stuff in Phobos which still uses std.regexp, we should probably make it so that std.regexp is _scheduled_ for deprecation rather than deprecated, but the changes still need to be made). Simply marking std.regexp as deprecated in its documentation isn't enough. I'm raising the issue so that someone who is actually familiar with std.regexp and std.regex can do the conversion.
>> Looks like I'm the one best suited for this, since I have extensive
>> experience with both modules and their internals.
>> In fact, I'm doing GSOC project aimed at enhancing current std.regex,
>> basically replacing implementation and extending interface quite a bit.
>> Still changes going to be backwards compatible, so it's about time to
>> switch all phobos to std.regex.
>> I'll make a pull request soon.
> Thanks! Remember that where possible, functions in Phobos' public API which would be affected by the change should have the old version kept temporarily as "scheduled for deprecation" in order to give people some time to convert over rather than immediately breaking their code. And if the old function is a template, then a pragma warning about the the change should be put inside it. You can look at what std.file is currently doing with functions scheduled for deprecation for examples. Don't worry too much about the exact messages. I can go and adjust them later. Just mark them as scheduled for deprecation.
>
> The current plan is that anything which is deprecated should be scheduled for deprecation for about 6 months, deprecated for 6 months, and then removed. But std.regex has been around long enough that I suspect that we can accelerate that process a bit in this case.
>
> In any case, thank you for taking the time to convert over Phobos to std.regex. Then we can finally move towards removing std.regexp.

It turns out far easier then expected but at the same time far nastier. There is *only one* function in phobos that use std.regexp it's listDir in std.file. Now I just provide another overload for it and boom  - forward reference bug:

std\conv.d(3762): Error: template std.conv.text(T...) forward reference
to template text(T...)
std\typecons.d(326): Error: template std.conv.text(T...) cannot deduce
template function from argument types !()(string,uint,string)
std\conv.d(3762): Error: template std.conv.text(T...) forward reference
to template text(T...)
std\typecons.d(327): Error: template std.conv.text(T...) cannot deduce
template function from argument types !()(string,uint)
std\conv.d(3762): Error: template std.conv.text(T...) forward reference
to template text(T...)
std\typecons.d(328): Error: template std.conv.text(T...) cannot deduce
template function from argument types
!()(string,_error_,string,_error_,string)
std\conv.d(3762): Error: template std.conv.text(T...) forward reference
to template text(T...)
std\typecons.d(331): Error: template std.conv.text(T...) cannot deduce
template function from argument types
!()(string,_error_,string,const(immutable(char)[]),string)
std\conv.d(3762): Error: template std.conv.text(T...) forward reference
to template text(T...)
std\typecons.d(326): Error: template std.conv.text(T...) cannot deduce
template function from argument types !()(string,uint,string)
std\conv.d(3762): Error: template std.conv.text(T...) forward reference
to template text(T...)
std\typecons.d(327): Error: template std.conv.text(T...) cannot deduce
template function from argument types !()(string,uint)
std\conv.d(3762): Error: template std.conv.text(T...) forward reference
to template text(T...)
std\typecons.d(328): Error: template std.conv.text(T...) cannot deduce
template function from argument types
!()(string,_error_,string,_error_,string)
std\conv.d(3762): Error: template std.conv.text(T...) forward reference
to template text(T...)
std\typecons.d(331): Error: template std.conv.text(T...) cannot deduce
template function from argument types
!()(string,_error_,string,const(immutable(char)[]),string)
std\typecons.d(364): Error: cannot evaluate injectNamedFields() at
compile time
std\typecons.d(364): Error: argument to mixin must be a string, not
(injectNamedFields())
std\regex.d(185): Error: template instance
std.typecons.Tuple!(uint,"startIdx",uint,"endIdx") error instantiating
std\file.d(3421):        instantiated from here: Regex!(char)


It works outside of std.file, so I'm not sure what to try next.
To reproduce just add std.regex to imports in std.file. And add this as
another overload for listDir.
/++ Ditto +/

string[] listDir(C)(in C[] pathname, Regex!char r, bool followSymLinks =
true)
{
     auto result = appender!(string[])();

     bool callback(DirEntry* de)
     {
         if(followSymLinks ? de.isDir : isDir(de.linkAttributes))
         {
             _listDir(de.name, &callback);
         }
         else if(true)//(!match(de.name,r).empty)
         {
             result.put(de.name);
         }

         return true; // continue
     }

     _listDir(pathname, &callback);

     return result.data;
}

> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos


-- 
Dmitry Olshansky