[phobos] Why ConvError and not ConvException?

[David Simcha]

Right.  I'm not arguing for insisting on perfect backwards 
compatibility, even at the source level.  I also don't think binary 
backwards compatibility is worth any effort at all yet (and it's largely 
moot since Phobos is mostly templates).  I'm just saying that we don't 
want to completely ignore the issue anymore.  If you're going to make 
breaking changes and there's an easy way to mitigate the breakage, then 
the breakages should be mitigated.  If there's no easy way to mitigate 
it, then advance notice should be given.  Given that the aliases have 
been included, I completely support the changes that have been made.

On 11/16/2010 7:29 PM, Jonathan M Davis wrote:
> On Tuesday, November 16, 2010 13:01:47 David Simcha wrote:
>> Once again, *please* put the aliases in for the old names for a few
>> releases.  I'm getting really, really sick of having my code break every
>> release now that D2 is supposed to be "stable" and I think other D users
>> are starting to feel the same way.
> I think that it should be general policy to use deprecated aliases where
> appropriate to reduce code breakages due to changes in Phobos, but since we're
> far from API stability, we're going to get breakages, and I really don't think
> that it's clear outside of anyone really paying attention to D development that
> Phobos is as unstable and immature as it is. It's definitely improving, but
> backwards incompatible changes do occur and will continue to occur for at least
> a little while regardless of the state of the compiler (e.g.
> std.file.lastModified() will presumably changed to return a std.datetime.SysTime
> was std.datetime has been approved, and you _can't_ make that change in a way
> that supports a deprecated backwards-compatible solution since it's only the
> return value that changes).
>
> In any case, I think that your point is a good one that we should try and only
> break code old code when it makes good sense to do so, and deprecated aliases
> can be a good way to reduce such breakages. Eventually, we'll likely have to
> move to a release cycle with major and minor releases where such breakages are
> only permitted in major releases, but that's a ways off yet I think.
>
> - Jonathan M Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>