On 2 March 2014 09:51, Martin Nowak <code@dawg.eu> wrote:
On 02/25/2014 06:00 AM, Manu wrote:
In lieu of a clear roadmap, I'm just going to list the things actively
holding me up on a daily basis.
Others encouraged to add theirs, maybe we'll see patterns emerge.

Just another wishlist thread?
Clearly for a roadmap you have to match demand with possible supply.
If you want to implement something or you found someone to do it for you put it on the Agenda (http://wiki.dlang.org/Agenda).

Well there's not really any record of short-term goals, and they also tend to change regularly; existing issues are fixed bringing other/new issues to the foreground, projects change, etc.
Surely it seems reasonable to define some short term goals according to the needs of people actually writing D code on a daily basis?

So, the point was to identify things that are actively interfering with peoples work on a daily basis.
If nobody wants to work on them, fine, but it needs to be known somewhere what things are a daily hassle.


1. Options to select CRT reference for DMD-Win64, and /Zl equiv option
to omit any such reference.
Not sure what this is for, won't -defaultlib= + manual linking already do the job? Is this very important or just a personal issue of yours?

MSCOFF objects embed a reference to the std lib they were built against, and intend to be linked against.
When linking against MSC code, if these references aren't embedded correctly or aren't matching, it creates a bunch of hassles when linking.
There are workarounds which suppress errors, and force linking of particular runtimes, but it's definitely preferable to just embed the proper CRT references in the objects when compiling, otherwise you run the risk of silencing legitimate errors from other sources and linking broken code.
Additionally, users who aren't linker experts will never work out how to link successfully. It can be very frustrating for anyone who doesn't understand the problem (and shouldn't have to).

Basically, if you interact DMD with MSC code, this really needs to be sorted out properly.
I consider this a critical issue to resolve if we are to say we support windows properly, and I for one do have to stuff around with these issues very frequently.


2. **Debugging**; concerted focus to tighten the experience. Classes,
enums, globals (and more) all don't work. Locals with the same name
appearing in multiple sub-scope's within the same function confuse the
debugger. Control statements (break, continue, etc) don't seem to emit
line numbers; single stepping skips right over them.
Debugging is important, but personally I have no interest to work on Windows debug information. Your best bet is to pair up with Rainer who already has a lot to do maintaining VisualD.

Walter and Rainer both have an interest in this, and Rainer has lots of existing pull requests that need attention.


3. ref doesn't accept rvalues. Can't declare ref locals (pointers change
semantics).
There seem to be competing DIPs. Please assemble the available information and any existing discussion outcome and update the wiki accordingly.
Also this might need a final discussion/voting round and at least a glance from Walter and Andrei.
If Kenji has enough time, he might be able to help you with the implementation.

Yes, I don't think this was ever fully resolved. It needs more discussion. I'm just trying to raise the topic.
I really don't want to spend time at dconf talking about this again.
It's so annoying trying to do any code with vectors and matrices without it.


I'd like to add one more:

4. Immutable AA's; ie, static maps. Surely the use of static maps are super common? I'm surprised this doesn't come up more often? The existing workaround (module constructor initialisation) is pretty annoying.