Jonathan M Davis wrote:
>
> Regardless, there will be one function - the version std.file.lastModified which just takes the file name - which will break the build of anyone using it, because the only thing changing in its signature is its return type (SysTime instead of d_time), so there's no way to overload it. Fortunately, however, I think that it's the only function in that boat.
>
> 

It needs to have a different name if its return type changes.

On Sunday 16 January 2011 09:39:34 Andrei Alexandrescu wrote:
> Could you replace the use of std.date within Phobos with std.datetime?

I've been working on it, but I've run into a few snags (such as the issues with deprecation messages). I expect to have it done this evening though.

- Jonathan M Davis

On Sunday 16 January 2011 09:46:57 Andrei Alexandrescu wrote:
> One possibility would be to have the legacy functions taking a d_time simply take a long for now (d_time was an alias for it I recall). Then you don't need to import std.date, and the warnings are gone.

I can do that. The problem is that then you don't get any messages when you use those functions, so when they get deprecated, it comes out of nowhere for you unless you've read the documentation or you've been using other d_time stuff and remembered that those functions take d_time. One suggestion that someone sent me was to temporarily templatize the function so that the pragma could be put inside the function as was done in some of the std.algorithm functions, but that _is_ a bit of a hack. I may have to do it that way though.

As I mentioned before, what we really need is a version of deprecated that is used to indicate that something is scheduled for deprecation rather than actually deprecated. And, of course - as I believe you've suggested in the past - being able to give deprecated the deprecation message would be a definite improvement as well. As it is, we need the pragma both when the symbol is scheduled to be deprcecated and after it's been deprecated (in addition to having actually marked it as deprecated), or the programmer doesn't know what to use instead, and the pragma isn't precise enough to avoid extraneous pragma messages.

- Jonathan M Davis

On Sunday 16 January 2011 11:48:36 Walter Bright wrote:
> Jonathan M Davis wrote:
> > Regardless, there will be one function - the version std.file.lastModified which just takes the file name - which will break the build of anyone using it, because the only thing changing in its signature is its return type (SysTime instead of d_time), so there's no way to overload it. Fortunately, however, I think that it's the only function in that boat.
> 
> It needs to have a different name if its return type changes.

Okay, then. If that's how you'd prefer to do it, then I guess that that's what I'll do - though nothing immediately comes to mind as an alternate name for lastModified. I'll have to brainstorm a bit, I guess.

- Jonathan M Davis

Jonathan M Davis wrote:
> On Sunday 16 January 2011 11:48:36 Walter Bright wrote:
> 
>> Jonathan M Davis wrote:
>> 
>>> Regardless, there will be one function - the version
>>> std.file.lastModified which just takes the file name - which will break
>>> the build of anyone using it, because the only thing changing in its
>>> signature is its return type (SysTime instead of d_time), so there's no
>>> way to overload it. Fortunately, however, I think that it's the only
>>> function in that boat.
>>> 
>> It needs to have a different name if its return type changes.
>> 
>
> Okay, then. If that's how you'd prefer to do it, then I guess that that's what I'll do - though nothing immediately comes to mind as an alternate name for lastModified. I'll have to brainstorm a bit, I guess.
>
>
> 

The reason is to not muck up existing user code, which I think is a worthy goal.

Great, thanks. In the meantime, unfortunately std.datetime breaks Phobos unittests at least on OSX with an internal error message:

Internal error: backend/cod2.c 4530


Andrei

On 1/16/11 7:34 PM, Jonathan M Davis wrote:
> On Sunday 16 January 2011 09:39:34 Andrei Alexandrescu wrote:
>> Could you replace the use of std.date within Phobos with std.datetime?
>
> I've been working on it, but I've run into a few snags (such as the issues with deprecation messages). I expect to have it done this evening though.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On Sunday 16 January 2011 18:16:56 Walter Bright wrote:
> Jonathan M Davis wrote:
> > On Sunday 16 January 2011 11:48:36 Walter Bright wrote:
> >> Jonathan M Davis wrote:
> >>> Regardless, there will be one function - the version std.file.lastModified which just takes the file name - which will break the build of anyone using it, because the only thing changing in its signature is its return type (SysTime instead of d_time), so there's no way to overload it. Fortunately, however, I think that it's the only function in that boat.
> >> 
> >> It needs to have a different name if its return type changes.
> > 
> > Okay, then. If that's how you'd prefer to do it, then I guess that that's what I'll do - though nothing immediately comes to mind as an alternate name for lastModified. I'll have to brainstorm a bit, I guess.
> 
> The reason is to not muck up existing user code, which I think is a worthy goal.

Oh, I agree. It's just that I've been thinking more along the lines of avoiding breaking changes unless it gets in the way to not make a breaking change. For instance, creating a new overload is easy enough, as is creating an alias when renaming a function, but being forced to rename a function just because the return type is changing is definitely getting in the way, so it wouldn't really have occurred to me to rename it unless I already thought that the name needed to be improved. But if we're taking the tact of never breaking user code without first deprecating whatever was there before, then we have deal with renaming functions and the like if that's what necessary to maintain the old function in the short term.

I guess that overall, I've been viewing the deprecation path as nice but not absolutely necessary, whereas you're viewing it as necessary. So, I'll just have to keep that in mind and change how I've been going about it. However, IIRC in this case, lastModified is the only change which would be a breaking change, so it doesn't require me to change much of what I've done except find a new name for lastModified.

- Jonathan M Davis

On Sunday 16 January 2011 18:34:30 Andrei Alexandrescu wrote:
> Great, thanks. In the meantime, unfortunately std.datetime breaks Phobos unittests at least on OSX with an internal error message:
> 
> Internal error: backend/cod2.c 4530

Well, the tests compile and pass on Linux and Windows (though the tests are currently disabled on Windows unless you build with version=testStdDateTime since, for some reason, when compiling the unittests for all of Phobos (instead of just std.datetime), the compiler runs out of memory if the unit tests for std.datetime are included: http://d.puremagic.com/issues/show_bug.cgi?id=5454 ).

From the message that you give there, it sounds like std.datetime's unit tests fail to compile on OSX due to a compiler bug, and I really don't know what to do about that. I could make it so that the unit tests only run on Linux instead of Posix (unless you use version=testdStdDateTime), but I don't know if std.datetime really works properly or OSX or not. At least with Windows, I know that the tests pass as long as I run them separately. I don't have a Mac to play around with though. So, I really don't know what to do about the Mac.

- Jonathan M Davis

Jonathan M Davis wrote:
>
> I guess that overall, I've been viewing the deprecation path as nice but not absolutely necessary, whereas you're viewing it as necessary.

In my experience of foisting breaking changes upon people, it can be very annoying to them. In my experience of breaking changes being foisted upon me, it can be very annoying to me. Hence my attitude about it :-)

On 1/16/2011 8:25 PM, Walter Bright wrote:
> 
> 
> Jonathan M Davis wrote:
>>
>> I guess that overall, I've been viewing the deprecation path as nice but not absolutely necessary, whereas you're viewing it as necessary.
> 
> In my experience of foisting breaking changes upon people, it can be very annoying to them. In my experience of breaking changes being foisted upon me, it can be very annoying to me. Hence my attitude about it :-)

One interesting side effect of breaking changes is that it introduces plateau releases.  Some subset of the user base stops upgrading at the release just prior to the breaking change for a long time.  It happens with compiler regressions.  I don't know that I can recall specific times when it's occurred due to druntime/phobos changes though.

IMHO, if it's not possible to fully stage the deprecation, minimizing the fast removal to a small set might be a reasonable path.

Later,
Brad