June 13, 2020
On 6/13/20 3:42 PM, Andrei Alexandrescu wrote:
> On 6/13/20 4:30 AM, Seb wrote:
>> I myself consider Phobos as low priority to maintain as it's basically frozen/dead code.
> 
> I was wondering what would be the drawbacks of defining an ultra-simple convention for versions of the standard library - with yearly granularity. Not being an expert in versioning I've always been coy to mention it, but how about trying it instead of the current stalemate. After all C++ does it (both with 3-year language versions and with things like std::tr1, std::tr2 etc) and it has a more dangerous modularity mechanism.
> 
> D's modularity is, or should be, rock solid. So then we could simply define "vYEAR" as versions of standard library modules. So:
> 
> // import the backward-compatible lib
> import std.algorithm;
> // import this year's algorithm with breaking changes
> import std.v2020.algorithm;
> // live dangerously, import work-in-progress
> import std.v2020.algorithm;

Eh, meant v2021 here.

June 13, 2020
On Saturday, 13 June 2020 at 19:52:16 UTC, Andrei Alexandrescu wrote:
> [snip]
>> D's modularity is, or should be, rock solid. So then we could simply define "vYEAR" as versions of standard library modules. So:
>> 
>> // import the backward-compatible lib
>> import std.algorithm;
>> // import this year's algorithm with breaking changes
>> import std.v2020.algorithm;
>> // live dangerously, import work-in-progress
>> import std.v2020.algorithm;
>
> Eh, meant v2021 here.

Something like below allows the user to specify what they want for all of phobos at the command or to import the specific one they want.

module std.algorithm;

version(std_latest) {
    version = std_2_92;
}
version(std_stable) {
    version = std_2_89;
}
version(std_2019) {
    version = std_2_89;
}
version(std_2_92) {
    public import 2_92.std.algorithm;
}
version(std_2_91) {
    public import 2_91.std.algorithm;
}
version(std_2_90) {
    public import 2_90.std.algorithm;
}
version(std_2_89) {
    public import 2_89.std.algorithm;
}
...

One problem is that if you allow people to make bug fixes to old phobos versions, then there is no way for the subsequent releases to get the updates as if you could with a git branch. You would have to do them all manually.

I also saw a suggestion about C++'s epoch proposal on another thread that was interesting.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html

June 13, 2020
On Saturday, 13 June 2020 at 19:42:47 UTC, Andrei Alexandrescu wrote:
> I wonder how well this would work.

I've thought about this before and I think it has a lot of potential (back when we were first looking at dub, this was my preferred version scheme and everyone shot it down :( )

I believe if the new version just public imported the old version and then you add new/breaking functionality there, you could bring it all together with minimal duplication and maximum help from the compiler in making it work, including using two incompatible versions simultaneously because they'd have different mangles from different module names.

I'd like to see us try to play with it.
June 13, 2020
On 6/13/20 4:37 PM, jmh530 wrote:
> One problem is that if you allow people to make bug fixes to old phobos versions, then there is no way for the subsequent releases to get the updates as if you could with a git branch. You would have to do them all manually.

It's not that bad. Typical newer iterations of phobos versions would simply list as public the unchanged symbols, so they are "deltas". Fixes to unchanged symbols would just propagate. Indeed fixes to changed symbols would need to be propagated manually, but even that may be mitigated by having the newer versions call the older versions on occasion.

More importantly versioning allows us to experiment with things such as "let's use assert and Expected instead of throwing throughout". These are definitely breaking APIs, but can be implemented easily in such a way that both the backward-compatible version and the new version share the same codebase. (You can wrap noexcept code in code that throws, etc.)

> I also saw a suggestion about C++'s epoch proposal on another thread that was interesting.
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html

Thanks!
June 13, 2020
On Saturday, 13 June 2020 at 18:56:55 UTC, Andrei Alexandrescu wrote:
> I didn't feel the need to add to provide detail because (a) most regulars in this forum already knew what I was going to say, and (b) nobody save for a few would share my opinion.
>
> But, I'll bite again, again to regret it.

I, for one, thought it was an interesting little write-up. Didn't expect it, my guess was that you were against the idea of using D to build something instead of a DSL, not the implementation.
June 13, 2020
On 6/13/20 6:52 PM, Dennis wrote:
> On Saturday, 13 June 2020 at 18:56:55 UTC, Andrei Alexandrescu wrote:
>> I didn't feel the need to add to provide detail because (a) most regulars in this forum already knew what I was going to say, and (b) nobody save for a few would share my opinion.
>>
>> But, I'll bite again, again to regret it.
> 
> I, for one, thought it was an interesting little write-up. Didn't expect it, my guess was that you were against the idea of using D to build something instead of a DSL, not the implementation.

I should add - the fact that dmd needs to be installed in order to build dmd is the proverbial insult added to the injury. Of course that ruined the carefully constructed AUTO_BOOTSTRAP option that allows building dmd on a fresh system.

I should also add - unless I'm looking at the wrong version, the old posix.mak has 654 lines. build.d has 1932 lines. But build.d also supplants the Windows 32/64 makefiles (589/57 lines), so the size is not way bigger. But that begs the question - given its liabilities, by what metric is build.d an improvement?
June 14, 2020
On Saturday, 13 June 2020 at 23:53:25 UTC, Andrei Alexandrescu wrote:
> On 6/13/20 6:52 PM, Dennis wrote:
>> On Saturday, 13 June 2020 at 18:56:55 UTC, Andrei Alexandrescu wrote:
>>> I didn't feel the need to add to provide detail because (a) most regulars in this forum already knew what I was going to say, and (b) nobody save for a few would share my opinion.
>>>
>>> But, I'll bite again, again to regret it.
>> 
>> I, for one, thought it was an interesting little write-up. Didn't expect it, my guess was that you were against the idea of using D to build something instead of a DSL, not the implementation.
>
> I should add - the fact that dmd needs to be installed in order to build dmd is the proverbial insult added to the injury. Of course that ruined the carefully constructed AUTO_BOOTSTRAP option that allows building dmd on a fresh system.
>
> I should also add - unless I'm looking at the wrong version, the old posix.mak has 654 lines. build.d has 1932 lines. But build.d also supplants the Windows 32/64 makefiles (589/57 lines), so the size is not way bigger. But that begs the question - given its liabilities, by what metric is build.d an improvement?

You used to have to update diffrent makefiles when adding a new file the build

Have you used the windows makefiles?
They didn't work without modification.

I do agree that build.d takes to long to build because of all the phobos-ness in it.
But if I want to debug it I can, at least.

whereas with those makefiles which have to work with digital mars make.
it's way harder.
June 13, 2020
On 6/13/20 8:00 PM, Stefan Koch wrote:
> On Saturday, 13 June 2020 at 23:53:25 UTC, Andrei Alexandrescu wrote:
>> On 6/13/20 6:52 PM, Dennis wrote:
>>> On Saturday, 13 June 2020 at 18:56:55 UTC, Andrei Alexandrescu wrote:
>>>> I didn't feel the need to add to provide detail because (a) most regulars in this forum already knew what I was going to say, and (b) nobody save for a few would share my opinion.
>>>>
>>>> But, I'll bite again, again to regret it.
>>>
>>> I, for one, thought it was an interesting little write-up. Didn't expect it, my guess was that you were against the idea of using D to build something instead of a DSL, not the implementation.
>>
>> I should add - the fact that dmd needs to be installed in order to build dmd is the proverbial insult added to the injury. Of course that ruined the carefully constructed AUTO_BOOTSTRAP option that allows building dmd on a fresh system.
>>
>> I should also add - unless I'm looking at the wrong version, the old posix.mak has 654 lines. build.d has 1932 lines. But build.d also supplants the Windows 32/64 makefiles (589/57 lines), so the size is not way bigger. But that begs the question - given its liabilities, by what metric is build.d an improvement?
> 
> You used to have to update diffrent makefiles when adding a new file the build

Awesome, now I only need to do surgery on build.d in an obscure function at line 1160 :o).

I'm not saying what was there was better. I'm just asking why there's so little progress.

> Have you used the windows makefiles?
> They didn't work without modification.
> 
> I do agree that build.d takes to long to build because of all the phobos-ness in it.
> But if I want to debug it I can, at least.
> 
> whereas with those makefiles which have to work with digital mars make.
> it's way harder.

I've often said gmake should be used for Windows to build dmd. Now we require dmd to build dmd...

And this time is on us. We can't blame the arcane make syntax. We got to define it all, and defined it to be even more arcane.

Where. Is. The. Progress.
June 14, 2020
On Saturday, 13 June 2020 at 18:56:55 UTC, Andrei Alexandrescu wrote:
> * Hundreds of lines of rules follow. It is natural to ask oneself to what extent they improve on makefile (or other build tools') syntax. I mean is this something easy on the eyes? Did build.d attain its objective?
>
>  582  /// BuildRule to generate man pages
>    583  alias man = makeRule!((builder, rule) {
>    584      alias genMan = methodInit!(BuildRule, (genManBuilder, genManRule) => genManBuilder
>    585          .target(env["G"].buildPath("gen_man"))
>    586          .sources([
>    587              dmdRepo.buildPath("docs", "gen_man.d"),
>    588              env["D"].buildPath("cli.d")])
>    589          .command([
>    590              env["HOST_DMD_RUN"],
>    591              "-I" ~ srcDir,
>    592              "-of" ~ genManRule.target]
>    593              ~ flags["DFLAGS"]
>    594              ~ genManRule.sources)
>    595          .msg(genManRule.command.join(" "))
>    596      );
>    597
>    598      const genManDir = env["GENERATED"].buildPath("docs", "man");
>    599      alias dmdMan = methodInit!(BuildRule, (dmdManBuilder, dmdManRule) => dmdManBuilder
>    600          .target(genManDir.buildPath("man1", "dmd.1"))
>    601          .deps([genMan, directoryRule(dmdManRule.target.dirName)])
>    602          .msg("(GEN_MAN) " ~ dmdManRule.target)
>    603          .commandFunction(() {
>    604              writeText(dmdManRule.target, genMan.target.execute.output);
>    605          })
>    606      );
>    607      builder
>    608      .name("man")
>    609      .description("Generate and prepare man files")
>    610      .deps([dmdMan].chain(
>    611          "man1/dumpobj.1 man1/obj2asm.1 man5/dmd.conf.5".split
>    612          .map!(e => methodInit!(BuildRule, (manFileBuilder, manFileRule) => manFileBuilder
>    613              .target(genManDir.buildPath(e))
>    614              .sources([dmdRepo.buildPath("docs", "man", e)])
>    615              .deps([directoryRule(manFileRule.target.dirName)])
>    616              .commandFunction(() => copyAndTouch(manFileRule.sources[0], manFileRule.target))
>    617              .msg("copy '%s' to '%s'".format(manFileRule.sources[0], manFileRule.target))
>    618          ))
>    619      ).array);
>    620  });
>

I agree, "chaining" is touted as one of the benefits of D, but whenever I see people using them they tend to be these types of monstrosities with many inefficiencies. The developers tend to not even know what's going on as most of the logic is hidden.
June 14, 2020
On Sunday, 14 June 2020 at 00:22:29 UTC, Andrei Alexandrescu wrote:
> Now we require dmd to build dmd...

We do anyway ever since the code base got converted from C++ to D.