On Tuesday, 1 September 2015 at 14:33:47 UTC, Iain Buclaw wrote:
> deprecating, and removing.  We need long term backwards compatibility, and Phobos just doesn't fit in that picture (yet).

Why do you need long term backwards compatibility?

On Tuesday, 1 September 2015 at 14:39:57 UTC, Ola Fosheim Grøstad wrote:
> Why do you need long term backwards compatibility?

It would be nice for bootstrapping... now that we need dmd to build dmd, it'd be really annoying if you need to install version X-3 to compile version X-2 to compile X-1 to finally compile version X just because of some stdlib instability.

On Tuesday, 1 September 2015 at 14:52:09 UTC, Adam D. Ruppe wrote:
> On Tuesday, 1 September 2015 at 14:39:57 UTC, Ola Fosheim Grøstad wrote:
>> Why do you need long term backwards compatibility?
>
> It would be nice for bootstrapping... now that we need dmd to build dmd, it'd be really annoying if you need to install version X-3 to compile version X-2 to compile X-1 to finally compile version X just because of some stdlib instability.

Don't forget about differences in FE versions between dmd/ldc/gdc - and the fact you want distribute most performant build possible.

On Tuesday, 1 September 2015 at 14:52:09 UTC, Adam D. Ruppe wrote:
> On Tuesday, 1 September 2015 at 14:39:57 UTC, Ola Fosheim Grøstad wrote:
>> Why do you need long term backwards compatibility?
>
> It would be nice for bootstrapping... now that we need dmd to build dmd, it'd be really annoying if you need to install version X-3 to compile version X-2 to compile X-1 to finally compile version X just because of some stdlib instability.

If that is an issue (I am not sure I understand why that scenario would arise) can't you pick a version of Phobos and make it part of the distribution, or mark some parts of Phobos stable and others unstable? I assume such stability issues also are relevant for commercial projects, not only DMD.

Seems to me that the most important advantage of moving to D is to attract developers that are unfamiliar with C++, so using selected parts of Phobos would make it a lot easier and fun for them to contribute.

I assume refactoring, high quality documentation and perhaps a tutorial too, of course. Seems to me that lowering the "anxiety threshold" could be an important move.

On Tuesday, 1 September 2015 at 15:02:37 UTC, Ola Fosheim Grøstad wrote:
> Seems to me that the most important advantage of moving to D is to attract developers that are unfamiliar with C++, so using selected parts of Phobos would make it a lot easier and fun for them to contribute.
>
> I assume refactoring, high quality documentation and perhaps a tutorial too, of course. Seems to me that lowering the "anxiety threshold" could be an important move.

Exactly. I was surprised to find out I couldn't use Phobos in ddmd. Raw D is still more pleasant than programming in C++, but not nearly as much fun as writing normal D code.

On Tuesday, September 01, 2015 09:44:17 Steven Schveighoffer via Digitalmars-d-announce wrote:
> On 9/1/15 6:48 AM, "Luís Marques  <luis@luismarques.eu> wrote:
> > On Sunday, 23 August 2015 at 05:17:33 UTC, Walter Bright wrote:
> >> We have made the switch from C++ DMD to D DMD!
> >
> > Is there a rough prediction of when the use of phobos in ddmd will start to be accepted?
>
> I'm not a dmd dev, but I'm not sure it will be accepted, since phobos is very unstable. We have to be cautious about making dmd breakable easily by a change to phobos.
>
> Of course, I think there is a baseline dmd/gdc/ldc that must be used to build dmd, so perhaps as long as you use phobos features that work there, it will be OK.

Plenty of Phobos is stable and hasn't changed in quite a while. We do sometimes deprecate stuff still, but there isn't much that gets deprecated at this point, and the deprecation cycle is about two years. The common problem would be regressions, and the compiler gets those as much or more often than Phobos does. But it is true that some stuff in Phobos changes occasionally, and that could affect how new a compiler you need to compile the current dmd.

Regardless of that though, I know that at least some of the dmd developers are against using Phobos simply because they don't want the dependency. It simplifies things if Phobos isn't in the mix. If you have to track down and fix a regression in the compiler, that's easier to do if you don't have to worry about the standard library being in the mix. The less that the compiler depends on, the less that the compiler devs have to worry about affecting the compiler. And if we need anything to be sure of anything working right, it's the compiler. Sure, there are some things in the standard library that might be nice to use in the compiler, but that doesn't mean that it's necessarily worth pulling in Phobos as a dependency, and if it's something that's really useful, maybe it's worth duplicating in the compiler code - or even making a version of it that's tailored to the compiler's needs.

- Jonathan M Davis

On 2 Sep 2015 5:31 am, "Jonathan M Davis via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote:
>
> On Tuesday, September 01, 2015 09:44:17 Steven Schveighoffer via
Digitalmars-d-announce wrote:
> > On 9/1/15 6:48 AM, "Luís Marques  <luis@luismarques.eu> wrote:
> > > On Sunday, 23 August 2015 at 05:17:33 UTC, Walter Bright wrote:
> > >> We have made the switch from C++ DMD to D DMD!
> > >
> > > Is there a rough prediction of when the use of phobos in ddmd will
start
> > > to be accepted?
> >
> > I'm not a dmd dev, but I'm not sure it will be accepted, since phobos is very unstable. We have to be cautious about making dmd breakable easily by a change to phobos.
> >
> > Of course, I think there is a baseline dmd/gdc/ldc that must be used to build dmd, so perhaps as long as you use phobos features that work there, it will be OK.
>
> Plenty of Phobos is stable and hasn't changed in quite a while. We do sometimes deprecate stuff still, but there isn't much that gets deprecated at this point, and the deprecation cycle is about two years. The common problem would be regressions, and the compiler gets those as much or more often than Phobos does. But it is true that some stuff in Phobos changes occasionally, and that could affect how new a compiler you need to compile the current dmd.
>

Don't forget, Phobos library maintainers love to use new features everywhere.  Tagging many functions with @nogc almost weeks after it was introduced in master was the last major backwards breaking change you did that I'm aware of.

Iain.

On Wednesday, 2 September 2015 at 03:31:12 UTC, Jonathan M Davis wrote:
> On Tuesday, September 01, 2015 09:44:17 Steven Schveighoffer via Digitalmars-d-announce wrote:
>> On 9/1/15 6:48 AM, "Luís Marques  <luis@luismarques.eu> wrote:
>> > On Sunday, 23 August 2015 at 05:17:33 UTC, Walter Bright wrote:
>> >> We have made the switch from C++ DMD to D DMD!
>> >
>> > Is there a rough prediction of when the use of phobos in ddmd will start to be accepted?
>>
>> I'm not a dmd dev, but I'm not sure it will be accepted, since phobos is very unstable. We have to be cautious about making dmd breakable easily by a change to phobos.
>>
>> Of course, I think there is a baseline dmd/gdc/ldc that must be used to build dmd, so perhaps as long as you use phobos features that work there, it will be OK.
>
> Plenty of Phobos is stable and hasn't changed in quite a while. We do sometimes deprecate stuff still, but there isn't much that gets deprecated at this point, and the deprecation cycle is about two years. The common problem would be regressions, and the compiler gets those as much or more often than Phobos does. But it is true that some stuff in Phobos changes occasionally, and that could affect how new a compiler you need to compile the current dmd.
>
> Regardless of that though, I know that at least some of the dmd developers are against using Phobos simply because they don't want the dependency. It simplifies things if Phobos isn't in the mix. If you have to track down and fix a regression in the compiler, that's easier to do if you don't have to worry about the standard library being in the mix. The less that the compiler depends on, the less that the compiler devs have to worry about affecting the compiler. And if we need anything to be sure of anything working right, it's the compiler. Sure, there are some things in the standard library that might be nice to use in the compiler, but that doesn't mean that it's necessarily worth pulling in Phobos as a dependency, and if it's something that's really useful, maybe it's worth duplicating in the compiler code - or even making a version of it that's tailored to the compiler's needs.
>
> - Jonathan M Davis

LOL.
Using « pure » D in DDMD is ugly. Then why even compiler was converted ?
Using phobos in ddmd is helpful - it will help to detect regressions in phobos.
There's an autotester so i don't think it can break the things.

On 02-Sep-2015 07:52, Iain Buclaw via Digitalmars-d-announce wrote:
> On 2 Sep 2015 5:31 am, "Jonathan M Davis via Digitalmars-d-announce"
> <digitalmars-d-announce@puremagic.com
> <mailto:digitalmars-d-announce@puremagic.com>> wrote:
>  >
>  > On Tuesday, September 01, 2015 09:44:17 Steven Schveighoffer via
> Digitalmars-d-announce wrote:
>  > > On 9/1/15 6:48 AM, "Luís Marques  <luis@luismarques.eu
> <mailto:luis@luismarques.eu>> wrote:
>  > > > On Sunday, 23 August 2015 at 05:17:33 UTC, Walter Bright wrote:
>  > > >> We have made the switch from C++ DMD to D DMD!
>  > > >
>  > > > Is there a rough prediction of when the use of phobos in ddmd
> will start
>  > > > to be accepted?
>  > >
>  > > I'm not a dmd dev, but I'm not sure it will be accepted, since
> phobos is
>  > > very unstable. We have to be cautious about making dmd breakable easily
>  > > by a change to phobos.
>  > >
>  > > Of course, I think there is a baseline dmd/gdc/ldc that must be used to
>  > > build dmd, so perhaps as long as you use phobos features that work
>  > > there, it will be OK.
>  >
>  > Plenty of Phobos is stable and hasn't changed in quite a while. We do
>  > sometimes deprecate stuff still, but there isn't much that gets
> deprecated
>  > at this point, and the deprecation cycle is about two years. The common
>  > problem would be regressions, and the compiler gets those as much or more
>  > often than Phobos does. But it is true that some stuff in Phobos changes
>  > occasionally, and that could affect how new a compiler you need to
> compile
>  > the current dmd.
>  >
>
> Don't forget, Phobos library maintainers love to use new features
> everywhere.  Tagging many functions with @nogc almost weeks after it was
> introduced in master was the last major backwards breaking change you
> did that I'm aware of.
>

Because the compiler and library releases go in lockstep we'd have to wait for another release cycle to even field-test @nogc. Not acceptable really.

Phobos ends up battle testing every new feature and if it wasn't new features will be definitely shipped in a broken state. Let's not forget that new D frontend features still have many bugs that stay undetected even after testing in Phobos.

-- 
Dmitry Olshansky

On Wed, Sep 2, 2015 at 12:37 PM, Dmitry Olshansky via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:

>
> Because the compiler and library releases go in lockstep we'd have to wait for another release cycle to even field-test @nogc. Not acceptable really.
>
> Phobos ends up battle testing every new feature and if it wasn't new features will be definitely shipped in a broken state. Let's not forget that new D frontend features still have many bugs that stay undetected even after testing in Phobos.
>
> --
> Dmitry Olshansky
>

Surely the compiler should always rely on the previous compiler + standard library versions.

Is there really a valid reason not to do this? Surely if the dog food is so bad no one should be eating?