Top-3 for 2.066

[Manu]

On 2 March 2014 09:51, Martin Nowak <code at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140302/c7dba7b9/attachment.html>