On 3/28/19 3:07 PM, ag0aep6g wrote:
> 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.

Deprecating RefRange is not abandon.

On Thu, Mar 28, 2019 at 02:47:49PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...]
> 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.

OK, *this* is going to be an even more drastic change.  So what happens with the current compiler bindings to druntime?


> 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.

That would be a very welcome change.

But I'd also have to warn that this may not be as trivial as you appear to think.  There's a lot of deep-seated stuff in the compiler that heavily ties it to the current druntime implementation.  Replacing all of that is going to be a non-trivial feat.

The TypeInfo stuff, for one thing, will take some work to reach your vision of a completely opt-in library.  Currently, trying to link without druntime will cause a bunch of errors related to missing TypeInfo's.  It *is* clowny, I'll give you that -- the compiler really should not be emitting this stuff (or should be using weak symbols for it) unless it's actually *used* by the user code.

Similarly, we should get rid of the implicit Monitor field in classes -- useless deadweight unless the user code needs synchronized classes.

Or the GC initialization in rt_init / rt_term.  Or, for that matter, the initialization code that packages command-line arguments into a string[] before invoking Dmain.  To achieve not linking any library for empty main() the compiler would have to stop emitting calls to rt_init / rt_term unless the program uses the GC.  And it'd have to emit main() as `main` rather than `Dmain` if you're going to want to omit the current standard initialization code.  (And don't forget the need to invoke module static ctors -- in topological order, which requires some amount of code to get right.)

And so on and so forth.

IOW, what we're looking at here is nothing short of what essentially boils down to D3.  I applaud this direction, but let's not kid ourselves that this is going to happen overnight.


T

-- 
Music critic: "That's an imitation fugue!"

On Thu, Mar 28, 2019 at 03:09:53PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> 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.

But if that's the case, the stuff in maintenance mode should at least receive maintenance fixes of the kind being proposed for RefRange? Let's agree that RefRange was a bad idea and all that.  But there are users using it that need fixes for the issues they encountered.  Even if said fixes are perhaps also just as bad of an idea as RefRange itself was to begin with, for the sake of maintenence we'd still be obligated to provide at least workarounds for current bugs?


> 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.

If you're thinking about dropping druntime altogether, that's no mere addition, that's a MAJOR change.  One that I'd welcome, to be frank, but it's not going to happen without major breakage of existing codebases. Are you sure you've thought this through?


T

-- 
The most powerful one-line C program: #include "/dev/tty" -- IOCCC

On Thursday, 28 March 2019 at 19:12:40 UTC, H. S. Teoh wrote:
> The TypeInfo stuff, for one thing, will take some work to reach your vision of a completely opt-in library.  Currently, trying to link without druntime will cause a bunch of errors related to missing TypeInfo's.

Not true - that was fixed like a year ago.

See http://dpldocs.info/this-week-in-d/Blog.Posted_2019_02_25.html#no-runtime-d

The code there compiles with no extra code; it just works.

and my "last year in D" post on the official blog called this out with the release (I just don't remember the link)


> Or the GC initialization in rt_init / rt_term.  Or, for that matter, the initialization code that packages command-line arguments into a string[] before invoking Dmain.

The GC is initialized on the first use.

Lots of movement in this direction already happened in 2018!

On 3/28/19 3:19 PM, H. S. Teoh wrote:
> On Thu, Mar 28, 2019 at 03:09:53PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
>> 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.
> 
> But if that's the case, the stuff in maintenance mode should at least
> receive maintenance fixes of the kind being proposed for RefRange?

Changing the entire standard library to accommodate wackiness in RefRange is a poor executive decision regardless. The recent changes must be undone.

On Thu, Mar 28, 2019 at 03:23:30PM -0400, destructionator--- via Digitalmars-d wrote:
> On Thursday, 28 March 2019 at 19:12:40 UTC, H. S. Teoh wrote:
[...]
> > Or the GC initialization in rt_init / rt_term.  Or, for that matter, the initialization code that packages command-line arguments into a string[] before invoking Dmain.
> 
> The GC is initialized on the first use.

Yes, but not calling rt_init still causes a segfault when you try to use the GC.  So, we're not quite there yet.


> Lots of movement in this direction already happened in 2018!

That's good to know.

I'm still wondering, though, how we're going to drop druntime while still maintain backward compatibility.  Or how we could skip the startup code that invokes module ctors and packages command-line args into string[].  It would be awesome if we could pull this off, but I don't currently see how we could do it without major breakage.


T

-- 
Why waste time learning, when ignorance is instantaneous? -- Hobbes, from Calvin & Hobbes

On 28.03.19 20:24, Andrei Alexandrescu wrote:
> Changing the entire standard library to accommodate wackiness in RefRange is a poor executive decision regardless. The recent changes must be undone.

No one is arguing in favor of doing what I've in my PRs on the issue. Not even me.

I've started that endeavor, because the only tangible response I got when I asked what do do was from Jonathan M Davis who said: "it could be argued that generic, range-based functions simply shouldn't ever be assigning one range to another."[1]

If you prefer and approve removing RefRange.opAssign instead, I'm all for that.

Also note that Walter himself has done similar pull requests:

https://github.com/dlang/phobos/pull/6900
https://github.com/dlang/phobos/pull/6903

He uses constructors instead of "wonky" `move`, but the effect with regards to issue 18657 is the same: RefRange.opAssign is not called. If that's an acceptable way to make Phobos compatible with RefRange, that's also fine with me.


[1] https://forum.dlang.org/post/mailman.1557.1521939012.3374.digitalmars-d@puremagic.com

On 28.03.19 20:43, ag0aep6g wrote:
> On 28.03.19 20:24, Andrei Alexandrescu wrote:
>> Changing the entire standard library to accommodate wackiness in RefRange is a poor executive decision regardless. The recent changes must be undone.
[...]
> He uses constructors instead of "wonky" `move`

correction: "wacky", not "wonky" ;)

On 3/28/19 3:31 PM, H. S. Teoh wrote:
> On Thu, Mar 28, 2019 at 03:23:30PM -0400, destructionator--- via Digitalmars-d wrote:
>> On Thursday, 28 March 2019 at 19:12:40 UTC, H. S. Teoh wrote:
> [...]
>>> Or the GC initialization in rt_init / rt_term.  Or, for that
>>> matter, the initialization code that packages command-line
>>> arguments into a string[] before invoking Dmain.
>>
>> The GC is initialized on the first use.
> 
> Yes, but not calling rt_init still causes a segfault when you try to use
> the GC.  So, we're not quite there yet.

That'd need to be fixed, and it should be possible without disrupting clients.

>> Lots of movement in this direction already happened in 2018!
> 
> That's good to know.
> 
> I'm still wondering, though, how we're going to drop druntime while
> still maintain backward compatibility.  Or how we could skip the startup
> code that invokes module ctors and packages command-line args into
> string[].  It would be awesome if we could pull this off, but I don't
> currently see how we could do it without major breakage.

Compiler flag.

On 3/28/19 3:43 PM, ag0aep6g wrote:
> On 28.03.19 20:24, Andrei Alexandrescu wrote:
>> Changing the entire standard library to accommodate wackiness in RefRange is a poor executive decision regardless. The recent changes must be undone.
> 
> No one is arguing in favor of doing what I've in my PRs on the issue. Not even me.

Yes, I saw your pain seeping through the lines. The valiant effort hasn't gone unnoticed and is appreciated.

> I've started that endeavor, because the only tangible response I got when I asked what do do was from Jonathan M Davis who said: "it could be argued that generic, range-based functions simply shouldn't ever be assigning one range to another."[1]

This is a sign things have gotten off the rail. Assignment should be accessible and have obvious semantics.

> If you prefer and approve removing RefRange.opAssign instead, I'm all for that.
> 
> Also note that Walter himself has done similar pull requests:
> 
> https://github.com/dlang/phobos/pull/6900
> https://github.com/dlang/phobos/pull/6903
> 
> He uses constructors instead of "wonky" `move`, but the effect with regards to issue 18657 is the same: RefRange.opAssign is not called. If that's an acceptable way to make Phobos compatible with RefRange, that's also fine with me.
> 
> 
> [1] https://forum.dlang.org/post/mailman.1557.1521939012.3374.digitalmars-d@puremagic.com 

RefRange is a cancer.

Changing all data structures and algorithms to support it is the cancer going into metastasis.

We must excise the cancerous tissue.