On Thu, Mar 28, 2019 at 01:56:08PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 3/28/19 1:42 PM, H. S. Teoh wrote:
> > On Thu, Mar 28, 2019 at 01:04:58PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...]
> > > Part of that is we've been cagey about defining copy and assignment semantics of ranges in a simple and comprehensive manner. It seems to me going with these is the right thing:
> > > 
> > > * Input ranges are copyable and assignable, and have pointer semantics (all copies refer to the same underlying position, and advancing one advances all others).
> > > 
> > > * Forward ranges are copyable and assignable, but distinct copies refer to distinct positions in the range such that advancing one does not advance the others.
> > > 
> > > * We don't support other semantics.
> > 
> > What about classes that wrap ranges?
> 
> Those must go. Supporting classes and structs within the same framework is a costly low-yield endeavor.

So this will be a major breaking change, since there's a significant amount of user code that currently relies on this functionality.  Which means we're seriously considering Phobos v2 here?  I'd support that. It's time to reverse all those decisions that in hindsight were poor ones.  Like autodecoding.


> > E.g., std.ranges.interfaces.
[...]
> > Since classes are reference types, this would mean it's impossible to use those interfaces with forward ranges or above, which is a show-stopping limitation (e.g., if you need to return two different range types selected at runtime -- the current solution is to wrap them in the appropriate class using std.ranges.interfaces).
> 
> The obvious solution is to use structs that wrap pointers or class references. We don't preclude virtuals and dynamic behavior.

IOW, all ranges will be required to be structs?  And if we need dynamic behaviour it will have to be a struct that overrides opAssign to copy the state of the underlying range (for forward ranges)?

I suppose that could work.  There will be friction, though, if you need to access the underlying class hierarchy (e.g., the struct would have to export some sort of API for casting the wrapped class reference to some interface or base class that you might want to pass into a function expecting such).


T

-- 
Life is too short to run proprietary software. -- Bdale Garbee

On 3/28/19 2:12 PM, ag0aep6g wrote:
> On 28.03.19 18:04, Andrei Alexandrescu wrote:
>> On 3/28/19 9:16 AM, ag0aep6g wrote:
>>> On 28.03.19 14:05, Andrei Alexandrescu wrote:
>>>> Then some ranges are not meant to be assignable.
>>>
>>> Should Phobos be compatible with those ranges?
> [...]
>> It seems to me going with these is the right thing:
>>
>> * Input ranges are copyable and assignable, and have pointer semantics (all copies refer to the same underlying position, and advancing one advances all others).
>>
>> * Forward ranges are copyable and assignable, but distinct copies refer to distinct positions in the range such that advancing one does not advance the others.
>>
>> * We don't support other semantics.
> 
> Are you going to actually change the range definitions in that way? Are you saying that I should wait until then with fixing range issues in Phobos?
> 
> I'd expect those new definitions to be years away from becoming reality. It doesn't seem wise to leave bugs open today just because you have vague plans for fundamental changes in the distant future.

We've been worrying too much about changing things.

On any given issue, even those that widely agreed to be clowny, two factions emerge. One advocates change and the other advocates against code breakage. Interestingly the factions are different depending on the issue, i.e. a given person may be in favor of change in one matter and in favor of backwards compatibility in another. At any rate, the result is years-long stalemate and trench warfare on the slightest problems.

We should do what C, C++, Java, C# and many other languages do - leave past mistakes in maintenance mode and move on with new stuff. It's like blockchain - once done, it can't be undone. You do a new one. C has about three ways of converting numbers to strings and back. C++ added a couple, poorly designed. Then they added a better one. And don't get me started about I/O (two ways of doing it in C, and another one in C++ that nobody in their right mind would use). Same with Java pre- and post-generics interfaces for comparing objects. It's just that if something is bad they define a better one and move on.

We have a language with virtually no global scope - a versioning engineer's dream. Yet we are coy to tap into that power. Instead, we wring hands over the breakages that would happen if we change std.json. The time is ripe for std.v2, which would do the right things and support simple migration.

On Thu, Mar 28, 2019 at 07:12:36PM +0100, ag0aep6g via Digitalmars-d wrote:
> On 28.03.19 18:04, Andrei Alexandrescu wrote:
[...]
> > It seems to me going with these is the right thing:
> > 
> > * Input ranges are copyable and assignable, and have pointer semantics (all copies refer to the same underlying position, and advancing one advances all others).
> > 
> > * Forward ranges are copyable and assignable, but distinct copies refer to distinct positions in the range such that advancing one does not advance the others.
> > 
> > * We don't support other semantics.
> 
> Are you going to actually change the range definitions in that way? Are you saying that I should wait until then with fixing range issues in Phobos?
> 
> I'd expect those new definitions to be years away from becoming reality. It doesn't seem wise to leave bugs open today just because you have vague plans for fundamental changes in the distant future.

The only way I can see this happening is if we start a new iteration of Phobos, like std.v2.* where these fundamental changes can be done in a way that isn't totally disruptive to existing code.  There would have to be a migration path from the current Phobos so that existing code can gradually move to the new APIs.

Implementing these changes directly in the current Phobos is going to break SO much code it will make Walter & Andrei's stance on stabilizing the language completely laughable.

(OTOH, I would welcome something like std.v2.*, where we can reverse those decisions that in hindsight were poorly made, like autodecoding. And getting rid of subpar modules like std.xml (and incorporating Jonathan's dxml in its place).)


T

-- 
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen

On 3/28/19 2:30 PM, H. S. Teoh wrote:
> The only way I can see this happening is if we start a new iteration of
> Phobos, like std.v2.*

There'd be carefully carved subsets per capability, such as std.v2.betterc.*, std.v2.nogc.*, std.v2.noexcept.*, std.v2.safe.

The capability sets can be combined in alphabetic ordering. E.g. std.v2.noexcept.nogc.* has the subset that uses no gc and no exceptions, but std.v2.nogc.noexcept does not exist.

Through the magic of public imports and aliasing there would be no code duplication. Introspection could help, too, a la "define public aliases for all @safe definitions in that module". Some improvements to ddoc might be needed to "see" through aliases.

On 3/28/19 2:41 PM, Andrei Alexandrescu wrote:
> On 3/28/19 2:30 PM, H. S. Teoh wrote:
>> The only way I can see this happening is if we start a new iteration of
>> Phobos, like std.v2.*
> 
> There'd be carefully carved subsets per capability, such as std.v2.betterc.*, std.v2.nogc.*, std.v2.noexcept.*, std.v2.safe.
> 
> The capability sets can be combined in alphabetic ordering. E.g. std.v2.noexcept.nogc.* has the subset that uses no gc and no exceptions, but std.v2.nogc.noexcept does not exist.
> 
> Through the magic of public imports and aliasing there would be no code duplication. Introspection could help, too, a la "define public aliases for all @safe definitions in that module". Some improvements to ddoc might be needed to "see" through aliases.

Oh, and druntime must go.

The whole distinction between the runtime library and the standard library is clowny and has more to do with poorly ported tradition from other languages, than with anything else.

We need one standard library that is entirely pay-as-you-go (e.g. empty main() means no library file is ever needed for linking) and that offers an opt-in continuum.

On 28.03.19 19:30, Andrei Alexandrescu wrote:
> We should do what C, C++, Java, C# and many other languages do - leave past mistakes in maintenance mode and move on with new stuff. It's like blockchain - once done, it can't be undone. You do a new one. C has about three ways of converting numbers to strings and back. C++ added a couple, poorly designed. Then they added a better one. And don't get me started about I/O (two ways of doing it in C, and another one in C++ that nobody in their right mind would use). Same with Java pre- and post-generics interfaces for comparing objects. It's just that if something is bad they define a better one and move on.
> 
> We have a language with virtually no global scope - a versioning engineer's dream. Yet we are coy to tap into that power. Instead, we wring hands over the breakages that would happen if we change std.json. The time is ripe for std.v2, which would do the right things and support simple migration.

I'm not against that at all, but I'm not convinced that you can make it happen quickly. Remember that this sub-thread started with a mention of my pull request that was open for a year, sitting idle most of the time.

So until new Phobos materializes some more, I'd appreciate if we could fix issue 18657 one way or the other in old Phobos.

On 3/28/19 2:48 PM, ag0aep6g wrote:
> On 28.03.19 19:30, Andrei Alexandrescu wrote:
>> We should do what C, C++, Java, C# and many other languages do - leave past mistakes in maintenance mode and move on with new stuff. It's like blockchain - once done, it can't be undone. You do a new one. C has about three ways of converting numbers to strings and back. C++ added a couple, poorly designed. Then they added a better one. And don't get me started about I/O (two ways of doing it in C, and another one in C++ that nobody in their right mind would use). Same with Java pre- and post-generics interfaces for comparing objects. It's just that if something is bad they define a better one and move on.
>>
>> We have a language with virtually no global scope - a versioning engineer's dream. Yet we are coy to tap into that power. Instead, we wring hands over the breakages that would happen if we change std.json. The time is ripe for std.v2, which would do the right things and support simple migration.
> 
> I'm not against that at all, but I'm not convinced that you can make it happen quickly.

Three solid engineers would make this a quarter's worth of work. I don't think we have them.

 Remember that this sub-thread started with a mention of
> my pull request that was open for a year, sitting idle most of the time.
> 
> So until new Phobos materializes some more, I'd appreciate if we could fix issue 18657 one way or the other in old Phobos.

For that I think we should bite the bullet and let RefRange go.

On Thu, Mar 28, 2019 at 02:30:24PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...]
> We've been worrying too much about changing things.

Wow.  That's a pretty drastic (and refreshing!) change of stance from the past years of insisting that we should do our utmost to maintain backward compatibility.  I, for one, welcome this change.


[...]
> We have a language with virtually no global scope - a versioning engineer's dream. Yet we are coy to tap into that power. Instead, we wring hands over the breakages that would happen if we change std.json. The time is ripe for std.v2, which would do the right things and support simple migration.
[...]

Yes, I welcome the idea of std.v2.  And we should provide reasonable migration paths to std.v2, so that after X number of years, we can deprecate the current stuff, and move std.v2.* to std.*.  (Or maybe leave it as std.v2.*, in case there will ever be a need for std.v3.*. I hope not, but hindsight is always 20/20 so it seems inevitable going forward.)


T

-- 
IBM = I Blame Microsoft

On 28.03.19 19:51, Andrei Alexandrescu wrote:
> Three solid engineers would make this a quarter's worth of work. I don't think we have them.
[...]
> For that I think we should bite the bullet and let RefRange go.

So new Phobos won't happen for a long while, and old Phobos gets abandoned instead of fixed. Can't say that I'm hyped.

On 3/28/19 2:56 PM, H. S. Teoh wrote:
> On Thu, Mar 28, 2019 at 02:30:24PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> [...]
>> We've been worrying too much about changing things.
> 
> Wow.  That's a pretty drastic (and refreshing!) change of stance from
> the past years of insisting that we should do our utmost to maintain
> backward compatibility.  I, for one, welcome this change.

Thanks. The irony of it all is that adding new stuff and leaving the old stuff in maintenance mode is simultaneously the rock-solid compatibility stance and the ultimate road to progress.

It does happen, and has happened several times in my lifetime, that an entire community is missing an important point. It seems we missed the point that change is not what we need... it's addition.