On Monday, 1 February 2021 at 02:49:37 UTC, Steven Schveighoffer wrote:
> On 1/31/21 7:43 PM, Der wrote:
>> On Monday, 1 February 2021 at 00:25:42 UTC, Steven Schveighoffer wrote:
>>> Probably a phobos 2.0 thing.
>> 
>> Is this under serious consideration, or is it merely the optimists' fervent dream.
>
> Walter, Andrei, Atila and I are discussing for about 4 months. I have only been involved since then, not sure what the plans were before that.
>
> This is not a facetious thing. We are trying to determine the best way to create a phobos v2 that does not break existing code. I don't know what it will look like, or if we can come up with something that is workable soon. But we are working on it. The thing that I'm most interested in is no autodecoding. But of course, with a place where we can create breaking changes that live in an "opt-in" space, it opens the door to a lot of other things that we may want to include.
>
> -Steve

I would like to have a clear path to _increment_ it right now:

https://github.com/dlang/phobos/pull/6730

A clear policy and a final word simple additions like that would be great.

On Monday, 1 February 2021 at 00:25:42 UTC, Steven Schveighoffer wrote:
> I have often wanted a lazy formatting feature where you aren't allocating but it returns a string-able thing that can be used as an input range. I was surprised that phobos doesn't provide this.

Most implementations in std.format produce the result from left to right. It looks like this has been done on purpose, though I do not fully understand why. Aside from a few corner cases it's mainly formatting floating point numbers, that does not do so yet. Pondering whether it's possible to making the floatingpoint algorithms completely @nogc I meanwhile think it might be possible to produce the results from left to right here too (with some local buffers and/or RYU printf or something similar). With that, it shouldn't be too difficult to put everything into a lazy range. (But still, it's a long road to go.)

Anyway I wonder a little bit what use cases there are for such a range?

On 2/2/21 3:51 AM, Paolo Invernizzi wrote:
> On Monday, 1 February 2021 at 02:49:37 UTC, Steven Schveighoffer wrote:
>> On 1/31/21 7:43 PM, Der wrote:
>>> On Monday, 1 February 2021 at 00:25:42 UTC, Steven Schveighoffer wrote:
>>>> Probably a phobos 2.0 thing.
>>>
>>> Is this under serious consideration, or is it merely the optimists' fervent dream.
>>
>> Walter, Andrei, Atila and I are discussing for about 4 months. I have only been involved since then, not sure what the plans were before that.
>>
>> This is not a facetious thing. We are trying to determine the best way to create a phobos v2 that does not break existing code. I don't know what it will look like, or if we can come up with something that is workable soon. But we are working on it. The thing that I'm most interested in is no autodecoding. But of course, with a place where we can create breaking changes that live in an "opt-in" space, it opens the door to a lot of other things that we may want to include.
>>
> 
> I would like to have a clear path to _increment_ it right now:
> 
> https://github.com/dlang/phobos/pull/6730
> 
> A clear policy and a final word simple additions like that would be great.

That's a prime example of what a phobos v2 would allow. No code breakage, and provides a saner interface for future projects.

-Steve

On Tuesday, 2 February 2021 at 18:50:00 UTC, Steven Schveighoffer wrote:
> On 2/2/21 3:51 AM, Paolo Invernizzi wrote:
>> On Monday, 1 February 2021 at 02:49:37 UTC, Steven Schveighoffer wrote:
>>>[...]
>> 
>> I would like to have a clear path to _increment_ it right now:
>> 
>> https://github.com/dlang/phobos/pull/6730
>> 
>> A clear policy and a final word simple additions like that would be great.
>
> That's a prime example of what a phobos v2 would allow. No code breakage, and provides a saner interface for future projects.
>
> -Steve

I underline that adding a new better method, is not a breakage ...

On 2/2/21 2:50 PM, Paolo Invernizzi wrote:
> On Tuesday, 2 February 2021 at 18:50:00 UTC, Steven Schveighoffer wrote:
>> On 2/2/21 3:51 AM, Paolo Invernizzi wrote:
>>> On Monday, 1 February 2021 at 02:49:37 UTC, Steven Schveighoffer wrote:
>>>> [...]
>>>
>>> I would like to have a clear path to _increment_ it right now:
>>>
>>> https://github.com/dlang/phobos/pull/6730
>>>
>>> A clear policy and a final word simple additions like that would be great.
>>
>> That's a prime example of what a phobos v2 would allow. No code breakage, and provides a saner interface for future projects.
>>
> 
> I underline that adding a new better method, is not a breakage ...
> 

Adding @nogc to a method that's overridable that was previously not @nogc is breakage. That's the point of the folks in that review.

-Steve

On Tuesday, 2 February 2021 at 20:03:18 UTC, Steven Schveighoffer wrote:
> On 2/2/21 2:50 PM, Paolo Invernizzi wrote:
>> On Tuesday, 2 February 2021 at 18:50:00 UTC, Steven Schveighoffer wrote:
>>> On 2/2/21 3:51 AM, Paolo Invernizzi wrote:
>>>> On Monday, 1 February 2021 at 02:49:37 UTC, Steven Schveighoffer wrote:
>>>>> [...]
>>>>
>>>> I would like to have a clear path to _increment_ it right now:
>>>>
>>>> https://github.com/dlang/phobos/pull/6730
>>>>
>>>> A clear policy and a final word simple additions like that would be great.
>>>
>>> That's a prime example of what a phobos v2 would allow. No code breakage, and provides a saner interface for future projects.
>>>
>> 
>> I underline that adding a new better method, is not a breakage ...
>> 
>
> Adding @nogc to a method that's overridable that was previously not @nogc is breakage. That's the point of the folks in that review.
>
> -Steve

I agree with you, that's why I simply suggested to _add_ a new better method, and pointed also to precedents for that practise in Phobos ...

But despite that, the point is NOT having a policy for such common improvements, and that why there was a call to authority ...

On 2/2/21 3:08 PM, Paolo Invernizzi wrote:
> On Tuesday, 2 February 2021 at 20:03:18 UTC, Steven Schveighoffer wrote:
>>
>> Adding @nogc to a method that's overridable that was previously not @nogc is breakage. That's the point of the folks in that review.
>>
> 
> I agree with you, that's why I simply suggested to _add_ a new better method, and pointed also to precedents for that practise in Phobos ...
> 
> But despite that, the point is NOT having a policy for such common improvements, and that why there was a call to authority ...

OK, I was misunderstanding what you were saying (I may still not understand it), but yes, we are trying to find a way to do these kinds of improvements.

-Steve

On Tuesday, 2 February 2021 at 20:33:03 UTC, Steven Schveighoffer wrote:
> On 2/2/21 3:08 PM, Paolo Invernizzi wrote:
>> On Tuesday, 2 February 2021 at 20:03:18 UTC, Steven Schveighoffer wrote:
>>>
>>> Adding @nogc to a method that's overridable that was previously not @nogc is breakage. That's the point of the folks in that review.
>>>
>> 
>> I agree with you, that's why I simply suggested to _add_ a new better method, and pointed also to precedents for that practise in Phobos ...
>> 
>> But despite that, the point is NOT having a policy for such common improvements, and that why there was a call to authority ...
>
> OK, I was misunderstanding what you were saying (I may still not understand it),

Sorry for my bad phrasing ... you are understanding it rightly :-P

> but yes, we are trying to find a way to do  these kinds of improvements.

Steven, it's a two years waiting for a trivial addition to an obsoleted (definition coming from the PR discussion) module.

This thing start to smell more like "we don't care" that "we are carefully studying how hight to put the bar"

On 2/3/21 4:03 AM, Paolo Invernizzi wrote:
> On Tuesday, 2 February 2021 at 20:33:03 UTC, Steven Schveighoffer wrote:
>> but yes, we are trying to find a way to do  these kinds of improvements.
> 
> Steven, it's a two years waiting for a trivial addition to an obsoleted (definition coming from the PR discussion) module.
> 
> This thing start to smell more like "we don't care" that "we are carefully studying how hight to put the bar"

Not sure how to answer this. I only got involved 4 months ago. I can't spend full time on it, I have an actual job. So I'm sparsely working on it.

And it's important to prove that what we want to do is feasible and workable with our system of development. That's not an easy task, I've already hit some dead ends.

-Steve

On Wednesday, 3 February 2021 at 14:34:42 UTC, Steven Schveighoffer wrote:
> On 2/3/21 4:03 AM, Paolo Invernizzi wrote:
>> On Tuesday, 2 February 2021 at 20:33:03 UTC, Steven Schveighoffer wrote:
>>> but yes, we are trying to find a way to do  these kinds of improvements.
>> 
>> Steven, it's a two years waiting for a trivial addition to an obsoleted (definition coming from the PR discussion) module.
>> 
>> This thing start to smell more like "we don't care" that "we are carefully studying how hight to put the bar"
>
> Not sure how to answer this. I only got involved 4 months ago. I can't spend full time on it, I have an actual job. So I'm sparsely working on it.

I definitely understand that, don't worry.

> And it's important to prove that what we want to do is feasible and workable with our system of development. That's not an easy task, I've already hit some dead ends.

That's why defining policies and procedures is the way to go: they open up to scalability.

That specific PR is just asking a very, very tiny and specific question. The answer to that can be generalised, and then can be generally applied to similar situation without posing the burden to reviewers.

I will try to make this discussion constructive: I've seen Atila has commented the PR, and the PR was labeled "Andrej" ... I will ping again Atila on that, let's see if we can score a goal here.