In article <cht9gl$20m8$1@digitaldaemon.com>, Walter says...
>So I'd like to kick off this thread as an opportunity for all to post their two Most Important Issues for D with respect to getting 1.0 done. By MIID, I mean pragmatic things like:
>
>1) compiler bugs
>2) language shortcomings with no reasonable workarounds
>3) issues that are fundamentally blocking projects from using or proceeding
>with D
>4) severe library faults

Walter: My top two are as follows:

1) Please solve both the parameter passing and string concatenation (~) problems when using string literals, plus the handling of parameter implicit conversion of char[], wchar[], and dchar[] to functions' problems.

# int main()
# {
#     char[]  sDynStr   = "";
#     wchar[] wsDynStr  = "";
#     wchar[] wsDynStr2 = "";
#     dchar[] dsDynStr  = "";
#
#     // This works
#     sDynStr   = "Initializing to 8-Bit";
#     wsDynStr  = "Initializing to 16-Bit";
#     wsDynStr2 = "Initializing to 16-Bit";
#     dsDynStr  = "Initializing to 32-bit";
#
#     // This always works
#     sDynStr  = "This is" ~ " a test!";
#
#     /+
#      ' But when I use the ~ operator it forces
#      ' the 2nd literal string to a char[]
#      ' thus causing the "cannot implicitly convert
#      ' expression "This is a test!"
#      ' of type char[15] to wchar[]" error.
#      '
#      +/
#     wsDynStr = "This is" ~ " a test!";
#     dsDynStr = "This is" ~ " a test!";
#
#     // This works - forced to cast() each literal string
#     wsDynStr = cast(wchar[])"This is" ~ cast(wchar[])" a test!";
#     dsDynStr = cast(dchar[])"This is" ~ cast(dchar[])" a test!";
#
#     // This works -  - forced to cast() a literal string with (x)s
#     wsDynStr = cast(wchar[])( "This is" ~ " a test!" );
#     dsDynStr = cast(dchar[])( "This is" ~ " a test!" );
#
#     return 0;
#
# } // end int main()

2) Stronger support for DLLs.
----------------------------------------
Here's a part of Matthew's post that touchs on the subject at: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/9166

<partial content>
I see four issues with DLLs and D. I'm interested to hear whether I've missed
any and, especially, what ideas people have for solving these issues in a
"Spirit of D" way (i.e. without all the clodhopping nonsense that is the
Java/.NET infrastructure):

1. Sharing/managing GC - I think this is the most important in the short/medium term

2. Being able to talk _classes_ not just _interfaces_ between link units. We can get a long way with interfaces, methinks, once GC sharing is handled, but still it'd be nice to work with classes as well, if simply achievable.

3. Versioning, i.e. avoiding DLL Hell

4. Security. Is there something simple and efficient that nonetheless addresses those handled by the heaving leviathan that is .NET?

Ancilary issues:

1. Serialisation as a part of the language??
</partial content>

Walter, thanks for asking! ;)

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

Walter wrote:

> So I'd like to kick off this thread as an opportunity for all to post their two Most Important Issues for D with respect to getting 1.0 done. By MIID, I mean pragmatic things like:
> 
> 1) compiler bugs
> 2) language shortcomings with no reasonable workarounds
> 3) issues that are fundamentally blocking projects from using or
> proceeding with D
> 4) severe library faults

A bugzilla (web bug tracking system) would be more apt for this task than a forum thread, wasn't one about to be set up at dsource?

Walter, the (php) MantisBT can be configured in no more than 20 minutes!
(it's what we're using at work and works really well.):

http://www.mantisbt.org/

The CVS version also allow for voting (sponsorship) of bugs.

1. Put "D language and compiler" in maintainance mode ASAP.
2. Improve Phobos. Phobos right now looks like some
bunch of crap put together.

- Sai

"Lynn Allan" <l_d_allan@adelphia.net> wrote in message news:chuk7d$2mrs$1@digitaldaemon.com...
> <alert comment="newbie">
>
> Reasonably stable and mature "official" gui library with enough widgets to put simple non-console apps together (may or may not be all that portable)

A gui library will probably be a good idea around version 2.0 or 3.0. A 1.0 language and core library is probably going to be too early to use to build complex apps or libraries. Look at AWT and how now Java Swing has various warts because of backwards compatibility with it.

> Reasonably stable and mature ide with symbolic debugger and step-into and step-over. If already available, documentation for it.

ah, yeah. that would be very helpful.

>
> </alert>
>
>

Change 0 to 1 in line 58 of parse.c :)
Reference return types would be great :)

You are doing a great job with D, and the above is just one of those wishes everyone has, but i would like this to be possible:

1)

class A
{
    this(){/*...*/}
    template constr(T)
    {
        this(T x){/*...*/}
    }

    mixin constr!(int);
    mixin constr!(float);
}

This code looks exelent but to turn on name overloading between the default constructor and the mixed ones, i would have to alias it. But how?

mixin constr!(int) somename;
alias somename.this this; //doesn't work

Someone mentioned something about combining mixin and alias
into one thing like: mixin constr!(int) as this; or something like that,
but i would be prefectlly happy with anything that did the job.

2)
a more usefull Phobos but this can wait, but it can wait until while
you are making a compiler and the language better.



"Walter" <newshound@digitalmars.com> wrote in message news:cht9gl$20m8$1@digitaldaemon.com...
> In some delightful ways, D is a victim of its own success. There's a lot
of
> traffic in the D newsgroups, sometimes getting to 100 messages per day.
Not
> a day goes by without new proposals for features. It's simply beyond my capacity to give these all the attention they deserve, or even to read
them
> all. I probably spend a minimum of 2 hours a day reading messages, and I could easilly spend 12 hours a day at it, and accomplish nothing else.
>
> Hence, I inadvertently overlook important issues. I know that this has
been
> frustrating to some people, and I apologize for it.
>
> So I'd like to kick off this thread as an opportunity for all to post
their
> two Most Important Issues for D with respect to getting 1.0 done. By MIID,
I
> mean pragmatic things like:
>
> 1) compiler bugs
> 2) language shortcomings with no reasonable workarounds
> 3) issues that are fundamentally blocking projects from using or
proceeding
> with D
> 4) severe library faults
>
> I don't mean things like:
>
> 1) D 2.0 issues
> 2) feature proposals like "It would be nice if ..."
> 3) minor irritants
> 4) philosophical issues
> 5) issues that have been beaten to death already <g>
>
> If a thread here exists for the topic, a reference to that thread would be nice rather than reproducing it.
>
> It's time to prioritize and get us on a rational, sensible path for releasing 1.0.
>
>

On Fri, 10 Sep 2004 15:18:03 -0700, Walter wrote:

> So I'd like to kick off this thread as an opportunity for all to post their two Most Important Issues for D with respect to getting 1.0 done. By MIID, I mean pragmatic things like:
> 
> 1) compiler bugs
> 2) language shortcomings with no reasonable workarounds

I'm not sure if this is a shortcoming, or just a feature request, but I'll mention it again: D's unit test facility is not usable for test driven development (because it's unnecessarily difficult to run a subset of tests) or for automated builds (because a single failure will halt execution of the test suite). I don't classify this as a showstopper bug, but I think it's at the very next level. To use D at my company, we would have to completely drop a significant language feature in favor of a library, because D doesn't work the way we do.

I have posted thoughts on the wiki about this, with a link to my original proposal. Even if that feature proposal is not a good solution, I believe it covers the problems well.

Mike Swieton
__
Following the light of the sun, we left the Old World.
	- Inscribed on Columbus' caravels

"Walter" <newshound@digitalmars.com> wrote in message news:cht9gl$20m8$1@digitaldaemon.com...
> Hence, I inadvertently overlook important issues. I know that this has been frustrating to some people, and I apologize for it.

> So I'd like to kick off this thread as an opportunity for all to post
their
> two Most Important Issues for D with respect to getting 1.0 done.

<alert comment="newbie">

Thanks for asking!

I've been impressed by how well the development model based on a "benevolent czar with inner sanctum meritocracy" is working with "D".

</alert>

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:chvkmg$2u6$1@digitaldaemon.com...
>
> "Lynn Allan" <l_d_allan@adelphia.net> wrote in message news:chuk7d$2mrs$1@digitaldaemon.com...
> > <alert comment="newbie">
> >
> > Reasonably stable and mature "official" gui library with enough widgets
to
> > put simple non-console apps together (may or may not be all that
portable)
>
> A gui library will probably be a good idea around version 2.0 or 3.0. A
1.0
> language and core library is probably going to be too early to use to
build
> complex apps or libraries. Look at AWT and how now Java Swing has various warts because of backwards compatibility with it.
>
> > Reasonably stable and mature ide with symbolic debugger and step-into
and
> > step-over. If already available, documentation for it.
>
> ah, yeah. that would be very helpful.
>
> >
> > </alert>

I hesitated to submit the 2 MIID that I did. Clearly they were at least somewhat outside what "The WB" was asking. And I appreciate your patient, gentle reply to this newbie.

However ...

I would speculate that any relatively general purpose language will have an "uphill battle" for acceptance and "critical mass" if gui apps are difficult to accomplish. Is there really a need for yet another language for embedded and console apps? I used AWT for a relatively simple freeware app and found it acceptable. If a gui library equivalent to AWT was available for "D", I would now be deciding whether to commence development on a freeware app now in the planning stage, or porting two existing freeware apps to "D".

Similarly, a development tool with a decent debugger is much easier to learn and use. I probably overuse debuggers, but the ability to step-into code and directly see what is going on with an object probably facilitates my "getting up to speed" with a new language by an order of magnitude.

In article <chvtiv$75r$1@digitaldaemon.com>, Lynn Allan says...
>
>I would speculate that any relatively general purpose language will have an "uphill battle" for acceptance and "critical mass" if gui apps are difficult to accomplish. Is there really a need for yet another language for embedded and console apps?

There are very few standalone languages that have shipped with GUI support.  In fact Java is just about the only one I can think of.  And Java totally scapped their GUI api and started over around version 1.4.

As for the need for a new system language, I think we do or I wouldn't be here. C++ is an incredibly powerful but I can't help but feel it could be better if it weren't stuck with all sorts of legacy issues.  D offers a chance to start fresh and so far I think Walter has done a tremendous job with the design.  If you want more out of D you're certainly welcome to make it whatever you want.  There are plenty of library features I'd like to see, but the groundwork has to be laid first--language issues, core library support (garbage collection, exceptions, threading)--before that level of work can really begin.

>Similarly, a development tool with a decent debugger is much easier to learn and use. I probably overuse debuggers, but the ability to step-into code and directly see what is going on with an object probably facilitates my "getting up to speed" with a new language by an order of magnitude.

Agreed.  I think Eclipse may be D's best shot at a native IDE, but I haven't been able to get the D plugin working yet (though I hope to find more time to play with it in the next week or so).  Again, this is something that the community could provide, as it isn't really necessary to get the compiler finished and such.


Sean

Lynn Allan wrote:
> I hesitated to submit the 2 MIID that I did. Clearly they were at least
> somewhat outside what "The WB" was asking. And I appreciate your patient,
> gentle reply to this newbie.
> 
> However ...
> 
> I would speculate that any relatively general purpose language will have an
> "uphill battle" for acceptance and "critical mass" if gui apps are difficult
> to accomplish. Is there really a need for yet another language for embedded
> and console apps? I used AWT for a relatively simple freeware app and found
> it acceptable. If a gui library equivalent to AWT was available for "D", I
> would now be deciding whether to commence development on a freeware app now
> in the planning stage, or porting two existing freeware apps to "D".
> 
> Similarly, a development tool with a decent debugger is much easier to learn
> and use. I probably overuse debuggers, but the ability to step-into code and
> directly see what is going on with an object probably facilitates my
> "getting up to speed" with a new language by an order of magnitude.

The thing is, neither of these issues are in Walter's hands. :)

Walter is the only one who can make improvements to the compiler itself, so it stands to reason that it be his primary focus.  The auxiliary code monkeys (that's us!) can handle most everything else.

 -- andy