On 3/28/2019 4:05 PM, ag0aep6g wrote:
> I don't mind you being against those changes, but the changes so far are hardly "large". Ignoring the tests, both my PRs combined add meager 20 lines. And that's for seven bug fixes.

Right, but those changes cut across a large number of algorithms, and will cause every algorithm implementer to do the same. That makes it a very large change. I'm glad I noticed this before a lot more work was expended in that direction.


> By the way, you recently made changes to `save` methods in std.utf:
> 
> https://github.com/dlang/phobos/pull/6900
> https://github.com/dlang/phobos/pull/6903
> 
> I'm not sure why you made those,

The problem I ran into was ranges that had const fields would fail, because one cannot assign to a const field. But one can construct a const field. Doing some digging, it became apparent that save() is equivalent to copy construction, and so should be implemented using copy construction.

Assignment and construction are fundamentally different, and save() is clearly a construction.


> but they touch the same kind of code as my PRs, and they actually fix the issue I was fixing, too. Are you planning on applying that pattern to all of Phobos, or just std.utf for some reason?

My immediate goal was simply to get phobos to compile with DIP1000. Over time, I expect a well-implemented save() function should use copy construction. I did write a PR to that effect:

https://github.com/dlang/phobos/pull/6905/files

Your advice on that would be appreciated.


> If you're going for all of Phobos, you might end up fixing issue 18657 as a side effect. But removing RefRange.opAssign would still be nice, because it's just weird.

Fixing RefRange.save() using copy construction, and ditching opAssign, would be acceptable.

On 29.03.19 00:30, Walter Bright wrote:
> The problem I ran into was ranges that had const fields would fail, because one cannot assign to a const field. But one can construct a const field. Doing some digging, it became apparent that save() is equivalent to copy construction, and so should be implemented using copy construction.

Is Phobos supposed to support ranges with const fields? Won't that be generality creep?

A quick test shows that all five examples from issue 18657 fail for ranges with const fields. With my changes, the first three work, and the other two don't fail in `save` anymore, but still in other places.

Supporting const fields will require at least the same amount of busywork as supporting RefRange, because the underlying issue is the same: Can ranges be non-assignable and should Phobos support such ranges?

[...]
> Fixing RefRange.save() using copy construction, and ditching opAssign, would be acceptable.

How does RefRange.save need fixing?

On Thursday, 28 March 2019 at 18:47:49 UTC, Andrei Alexandrescu 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.
>
> 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.

yes, Yes, YES!  Now that's a vision I can get behind.  Time to start dusting off my DMD and druntime forks.  I'm in.

Mike

On Thursday, 28 March 2019 at 18:30:24 UTC, Andrei Alexandrescu wrote:

> We've been worrying too much about changing things.

Wow! That is refreshing to read.

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

Hear, hear.  It applies to much outside of software as well.

Reading this I'm getting all psyched about D again.

Mike

On Thursday, 28 March 2019 at 20:14:19 UTC, Andrei Alexandrescu wrote:
> On 3/28/19 3:12 PM, H. S. Teoh wrote:
>> I applaud this direction, but let's not kid ourselves
>> that this is going to happen overnight.
>
> Or at all. The entire effort would require three strong like-minded engineers, and I don't know them.

Or a team of subordinate apprentice/junior engineers (who have demonstrated sufficient potential) working under the mentorship of a master who is willing to make an investment.

Mike

On Thursday, 28 March 2019 at 19:23:30 UTC, destructionator wrote:
> 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)
[...]

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

Yes, the release that enabled that was 2.079 (https://dlang.org/changelog/2.079.0.html)

It started with `ModuleInfo` which set a precedent for then doing `TypeInfo` and `Throwable`

https://github.com/dlang/dmd/pull/7395
https://github.com/dlang/dmd/pull/7768
https://github.com/dlang/dmd/pull/7799
https://github.com/dlang/dmd/pull/7786

The work is also ongoing with Dan Printzell recently deciding on decoupling `TypeInfo` from the runtime hooks for his GSoC proposal (https://forum.dlang.org/post/dunewuhfbkqnbtemicmk@forum.dlang.org).  Let's be sure to give him our support.

Mike

On 3/28/2019 5:40 PM, ag0aep6g wrote:
> On 29.03.19 00:30, Walter Bright wrote:
>> The problem I ran into was ranges that had const fields would fail, because one cannot assign to a const field. But one can construct a const field. Doing some digging, it became apparent that save() is equivalent to copy construction, and so should be implemented using copy construction.
> 
> Is Phobos supposed to support ranges with const fields? Won't that be generality creep?

Phobos already has such ranges, such as Repeat.

Besides, if you accept the notion that save() performs a construction, not an assignment, and that construction and assignment are fundamentally different, then save() must be implemented using construction.

I can't think of a case where this would break existing code.


> A quick test shows that all five examples from issue 18657 fail for ranges with const fields. With my changes, the first three work, and the other two don't fail in `save` anymore, but still in other places.
> 
> Supporting const fields will require at least the same amount of busywork as supporting RefRange, because the underlying issue is the same: Can ranges be non-assignable and should Phobos support such ranges?

Ranges don't need to be assignable. ForwardRanges need to supply a save(), which means copy construction, not assignment.


>> Fixing RefRange.save() using copy construction, and ditching opAssign, would be acceptable.
> 
> How does RefRange.save need fixing?

I thought you wrote that copy construction would make RefRange work?

On Thursday, 28 March 2019 at 18:30:24 UTC, Andrei Alexandrescu wrote:
> On 3/28/19 2:12 PM, ag0aep6g wrote:
>> [...]
>
> 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.
>
> [...]

This is a complete 180 from what you were saying a year ago. What happened?

On 3/28/19 10:03 PM, Jonathan Marler wrote:
> On Thursday, 28 March 2019 at 18:30:24 UTC, Andrei Alexandrescu wrote:
>> On 3/28/19 2:12 PM, ag0aep6g wrote:
>>> [...]
>>
>> 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.
>>
>> [...]
> 
> This is a complete 180 from what you were saying a year ago. What happened?

"I'd rather be right than consistent." -- Winston Churchill

On Thursday, 28 March 2019 at 20:02:17 UTC, Andrei Alexandrescu wrote:

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

D is so powerful, this can also be done in other ways as well.

As Andrei alluded to in another post, we just need to embrace addition.  Keep the existing logic path in place, and create a new one that does what we want it to do.  With design-by-introspection, and probably a number of other awesome D facilities, the correct logic path can be chosen at compile-time based on what the user has declared in their code.

Another idea is allowing "module inheritance" for lack of a better term.  Users can "inherit" from an "abstract" module but override the default startup and shutdown logic.  Perhaps we refactor the current logic path to inherit from this "abstract" module but add all of the existing startup and shutdown implementation as overrides.  The compiler is then modified to "inherit" from that module by default.  Users that don't want the default can "inherit" from the "abstract" module and provide their own implementation.

I obviously haven't thought all of this through; I'm just trying to illustrate D is so powerful that there are other ways to achieve a similar result without always resorting to compiler flags, though a compiler flag may be the best option.

Mike