Dconf AGM draft agenda
Seb
seb at wilzba.ch
Wed Apr 3 11:53:11 UTC 2019
On Wednesday, 3 April 2019 at 00:10:53 UTC, Nicholas Wilson wrote:
> The Dconf AGM draft agenda is up at
> https://github.com/thewilsonator/Dlang-AGM
>
> If you feel that something is missing or I've messed something
> up please do open a PR.
Thanks a lot for this!
It would be super nice to have handy links to the relevant GH
PRs, Bugzilla issue or forum discussion.
Also each point should have a short description, because I don't
know what you want to discuss with e.g. "Stuff from
github.com/truedat101/dlang-sv-community".
Anyhow, a few points:
> Deprecate autodecode – plan of action
tl;dr: the only way we can get rid of it is std.v2
> Dub tester to regression scan for dmd releases - Neia
How is this different to the existing project tester?
> 64 compiler release for windows
It's listed twice.
In short: the release setup is pretty complicated and only Martin
has all the VMs required for the build setup.
Also, you might want to add to your list that the binaries for
Windows are no longer signed.
> int[$] arr = [1,2,3,4];
I wouldn't get my hopes up for this one.
A DMD PR has been reverted and then closed.
https://github.com/dlang/dmd/pull/3615
https://github.com/dlang/dmd/pull/4377
Since then `staticArray` has been added to Phobos:
> changes w.r.t DIP1000, c.f. dlang.org#2453
the subpoints seem unrelated.
> Quality of documentation
It's pretty bad. DMD documentation is almost unusable, for
druntime many modules don't have long descriptions or examples.
Phobos is a lot better, but the ddoc <-> ddox duplication is
still around.
The tour.dlang.io should have been revisited and reworked a long
time ago, but no one got around (in short: we want to have a more
natural intro for readers and show off D features in the
beginning, not end).
> Transition from DMC+OPTLINK to msvc/mingw + lld
I have tried this before. Walter will definitely object to this.
Other people also gave it a shot, see e.g.
https://github.com/dlang/dmd/pull/8347
https://github.com/dlang/dmd/pull/9085
With mingwg + lld there is also this problem:
https://issues.dlang.org/show_bug.cgi?id=19760
At least, dub now does the sensible thing:
https://github.com/dlang/dub/pull/1661
> FreeBSD 11/12
It's a mess and as almost no one uses D on FreeBSD, this doesn't
move forward:
https://github.com/dlang/dmd/pull/8567
FWIW toolchain triplet selection would have been nice too:
https://github.com/dlang/dmd/pull/8020
> State of std.experimental
The entire idea of std.experimental kinda failed, because
breaking changes can't be SemVer-ed,
If you're asking whether anything can be stabilized, we're far
from it:
- stdx.logger: people want a @nogc logger (and IIRC there were
some API issues)
- stdx.checkedint: it's not even @safe by default (see e.g.
https://github.com/dlang/phobos/pull/6369,
https://github.com/dlang/phobos/pull/5928,
https://github.com/dlang/phobos/pull/6550)
- stdx.allocator: still changes happening very often. The
community fork diverged and is usable with betterC
(https://github.com/dlang-community/stdx-allocator). There are
also quite a few bugzilla issues on it
- stdx.typecons: probably the only module that could be
stabilized (though it only contains two functions)
I'm not sure what to do with wrap as the existing wrap would need
to be deprecated and removed, but we could stabilize Final (D's
head-const):
https://dlang.org/phobos/std_experimental_typecons.html#.Final
> DMD as a library
With stuff like https://github.com/dlang/dmd/pull/9507, it's a
constant battle :/
> Get bugzilla under control (prioritisation)
We tried quite a few things over the last years:
- #dbugfix campaign
- voting on Bugzilla issues
Currently, we're back to people complaining loudly on the NG
about very important issues as this is the only way to grab
attention.
About a year ago, I started an internal discussion about moving
the issues to GitHub. I tested a potential migration and it
looked pretty promising. The two big downsides were:
- issue numbers would be different (though a redirect on
issues.dlang.org and mentioning the original issue number should
help greatly with that. Furthermore, we could create empty
"dummy" issues to align the issue numbers if deemed necessary)
- no longer in one global issue database (though since GitHub
supports issue transfers, probably not a big problem anymore)
In the end it wasn't done because of the fear of loosing control
over the issue data as the only way to programmatically export
them is the GitHub API which is severely rate-limited. Though to
be honest, at the moment Brad is the only with access to
issues.dlang.org (and no one else to my knowledge is keeping
backups of issues.dlang.org).
The migration script is here:
https://github.com/wilzbach/bugzilla-migration
More information about the Digitalmars-d
mailing list