On 11/28/2016 08:42 AM, Andrea Fontana wrote:
> On Monday, 28 November 2016 at 13:34:42 UTC, Andrei Alexandrescu wrote:
>> On 11/28/2016 04:13 AM, Andrea Fontana wrote:
>>> Hoping std.v2.stdio works and it's an alias to std.stdio.
>>
>> That doesn't work - how do you later make breaking changes to
>> std.v2.stdio? We'd be missing the very point of doing this. -- Andrei
>
> It's just an api level. When you need a breaking change all modules will
> be updated to v3 as alias except the edited ones.
>
> V3 it just like a commit-id on github.

I see - although that's an awesome idea for github, it seems excessive to bump the version of the entire stdlib when we want to transition one module or package of it. -- Andrei

On Monday, 28 November 2016 at 13:51:13 UTC, Andrei Alexandrescu wrote:
> On 11/28/2016 08:42 AM, Andrea Fontana wrote:
>> On Monday, 28 November 2016 at 13:34:42 UTC, Andrei Alexandrescu wrote:
>>> On 11/28/2016 04:13 AM, Andrea Fontana wrote:
>>>> Hoping std.v2.stdio works and it's an alias to std.stdio.
>>>
>>> That doesn't work - how do you later make breaking changes to
>>> std.v2.stdio? We'd be missing the very point of doing this. -- Andrei
>>
>> It's just an api level. When you need a breaking change all modules will
>> be updated to v3 as alias except the edited ones.
>>
>> V3 it just like a commit-id on github.
>
> I see - although that's an awesome idea for github, it seems excessive to bump the version of the entire stdlib when we want to transition one module or package of it. -- Andrei

It's just a simple tag. And I hope that breaking changes are not that frequent!
I think that on worst case there will be a new api level every dmd release. It just happens, but in this way it is managed in a better way. If needed we can use API_LEVEL_DMD_2071_3 as identifier. But IMO PHOBOS_API_LEVEL_2 makes more sense.

It would be really easy to mantain a back-compatibility. Just select the right api level, and you can still use new dmd version! Something similar really works fine with android api_level.

On 29/11/2016 3:01 AM, Andrea Fontana wrote:
> On Monday, 28 November 2016 at 13:51:13 UTC, Andrei Alexandrescu wrote:
>> On 11/28/2016 08:42 AM, Andrea Fontana wrote:
>>> On Monday, 28 November 2016 at 13:34:42 UTC, Andrei Alexandrescu wrote:
>>>> On 11/28/2016 04:13 AM, Andrea Fontana wrote:
>>>>> Hoping std.v2.stdio works and it's an alias to std.stdio.
>>>>
>>>> That doesn't work - how do you later make breaking changes to
>>>> std.v2.stdio? We'd be missing the very point of doing this. -- Andrei
>>>
>>> It's just an api level. When you need a breaking change all modules will
>>> be updated to v3 as alias except the edited ones.
>>>
>>> V3 it just like a commit-id on github.
>>
>> I see - although that's an awesome idea for github, it seems excessive
>> to bump the version of the entire stdlib when we want to transition
>> one module or package of it. -- Andrei
>
> It's just a simple tag. And I hope that breaking changes are not that
> frequent!
> I think that on worst case there will be a new api level every dmd
> release. It just happens, but in this way it is managed in a better way.
> If needed we can use API_LEVEL_DMD_2071_3 as identifier. But IMO
> PHOBOS_API_LEVEL_2 makes more sense.
>
> It would be really easy to mantain a back-compatibility. Just select the
> right api level, and you can still use new dmd version! Something
> similar really works fine with android api_level.

Instead of "API_LEVEL_DMD_*" this already works:

static if (__VERSION__ >= 2072)

On Monday, 28 November 2016 at 13:51:13 UTC, Andrei Alexandrescu wrote:
> On 11/28/2016 08:42 AM, Andrea Fontana wrote:
>> On Monday, 28 November 2016 at 13:34:42 UTC, Andrei Alexandrescu wrote:
>>> On 11/28/2016 04:13 AM, Andrea Fontana wrote:
>>>> Hoping std.v2.stdio works and it's an alias to std.stdio.
>>>
>>> That doesn't work - how do you later make breaking changes to
>>> std.v2.stdio? We'd be missing the very point of doing this. -- Andrei
>>
>> It's just an api level. When you need a breaking change all modules will
>> be updated to v3 as alias except the edited ones.
>>
>> V3 it just like a commit-id on github.
>
> I see - although that's an awesome idea for github, it seems excessive to bump the version of the entire stdlib when we want to transition one module or package of it. -- Andrei

Agreed. In other hand, we may want to evaluate all or a big part of Phobos to the new version instead of project-by-project migration torment. std2.*/std.v2.* or something like that. Also we need split a code, that should be only generic, only precompiled, only inlined, and other code. This will be very helpful for painless evaluation. --Ilya

On Monday, 28 November 2016 at 14:03:31 UTC, rikki cattermole wrote:
> On 29/11/2016 3:01 AM, Andrea Fontana wrote:
>> On Monday, 28 November 2016 at 13:51:13 UTC, Andrei Alexandrescu wrote:
>>> [...]
>>
>> It's just a simple tag. And I hope that breaking changes are not that
>> frequent!
>> I think that on worst case there will be a new api level every dmd
>> release. It just happens, but in this way it is managed in a better way.
>> If needed we can use API_LEVEL_DMD_2071_3 as identifier. But IMO
>> PHOBOS_API_LEVEL_2 makes more sense.
>>
>> It would be really easy to mantain a back-compatibility. Just select the
>> right api level, and you can still use new dmd version! Something
>> similar really works fine with android api_level.
>
> Instead of "API_LEVEL_DMD_*" this already works:
>
> static if (__VERSION__ >= 2072)

Compiler version should be split from a library versions. --Ilya

On Monday, 28 November 2016 at 14:09:10 UTC, Ilya Yaroshenko wrote:
>> Instead of "API_LEVEL_DMD_*" this already works:
>>
>> static if (__VERSION__ >= 2072)
>
> Compiler version should be split from a library versions. --Ilya

But I can't set from compiler command line, I think. Something like:

dmd my_old_source.d -version=PHOBOS_API_LEVEL_2

And I think that inside phobos source a lot of breaking changes simply override old code and checking __VERSION__ is not useful at all. Am I wrong?

On Monday, 28 November 2016 at 14:15:21 UTC, Andrea Fontana wrote:
> On Monday, 28 November 2016 at 14:09:10 UTC, Ilya Yaroshenko wrote:
>>> Instead of "API_LEVEL_DMD_*" this already works:
>>>
>>> static if (__VERSION__ >= 2072)
>>
>> Compiler version should be split from a library versions. --Ilya
>
> But I can't set from compiler command line, I think. Something like:
>
> dmd my_old_source.d -version=PHOBOS_API_LEVEL_2
>
> And I think that inside phobos source a lot of breaking changes simply override old code and checking __VERSION__ is not useful at all. Am I wrong?

I propose Phobos to be an a packed by default collection of libraries with clear dependencies and community support. A package version should be overridable in dub configuration. This is what we need to involve companies to invest their efforts in dlang infrastructure. --Ilya

On 11/28/16 9:09 AM, Ilya Yaroshenko wrote:
> Compiler version should be split from a library versions. --Ilya

On 11/28/16 9:26 AM, Ilya Yaroshenko wrote:
> I propose Phobos to be an a packed by default collection of libraries
> with clear dependencies and community support. A package version should
> be overridable in dub configuration. This is what we need to involve
> companies to invest their efforts in dlang infrastructure. --Ilya

This is interesting stuff but I don't know of any precedent, so we'd be taking risks trying this. All language platforms I know of ship with one compiler tied to one fixed standard library implementation. (Then, third party libraries come on top of that.) The obvious issue with not doing that is dealing with maintaining a fuzzy combinatorial number of setups instead of one. The risks may, of course, be justified if this turns out to be a nice innovation but definitely the tradeoffs must be analyzed properly.

Martin, what do you think of this?


Andrei

On Monday, 28 November 2016 at 14:59:28 UTC, Andrei Alexandrescu wrote:
> All language platforms I know of ship with one compiler tied to one fixed standard library implementation.

We have a small community without commercial support but 3 compilers, large standard library and large ambitions to extend it more. We can / should split dependencies and make things clear. Travis, Circle CI, and Appveyor are very helpful. --Ilya

On Monday, November 28, 2016 14:09:10 Ilya Yaroshenko via Digitalmars-d wrote:
> Compiler version should be split from a library versions. --Ilya

While that might theoretically be nice, I don't think that it's particularly realistic, and it's definitely not how things have functioned for us historically. dmd and druntime are definitely too interconnected to separate those, and Phobos relies on druntime, so to some extent at least, it's tied to the version of druntime. It's also the case that it's often tied to a specific version of the compiler, because there's a feature change, and Phobos has to be updated accordingly (e.g. Walter has been making various improvements to @safe of late, and that has required changes in Phobos). The APIs of druntime and Phobos are reasonably stable, but they aren't completely stable, and their ABIs aren't stable. We're not constantly changing them, but there is no guarantee that they stay the same from release to release. We just try and ensure that user code that built and ran with the previous release continues to do so with the current one. There is no attempt to ensure that Phobos from one release builds with another, and it would make updating stuff way more of a pain if we had to worry about that. There is also no attempt to make it so that code _built_ with the previous release will work with the current one.

It's expected that if you're updating the compiler, you're going to update druntime and Phobos. And I don't think that that's unreasonable. It's actually pretty normal. I don't know of any language that separates their compiler releases from their standard library releases. They always go together. That's part of what comes with them being standard.

- Jonathan M Davis