This newsgroup has been extremely interesting so far - there have been a lot of very interesting discussions.  What I'm wondering now is how the open issues will move towards resolution?  And, as a precursor to that discussion, what is the list of actual open issues?  What is in for sure, and what is on the maybe list?

Personally, I'm very interested in seeing the resolution to some of the issues that have been raised.  To this end, I'd like to get Walter's feedback on some of the big issues that have been well debated - where are the issues going?  Are you considering adding some new elements that weren't in the original spec?  Reconsidering old ones?

Here are some of the major issues I'd like Walter to comment on:

--- Generics ---
I take it from Walter's posts and from the general sentiment, that some form of Generics is desirable - are there any candidates looking at all likely?

--- Operator Overloading ---
Well, we've had quite a bun fight over operator overloading. ;-)  Is it in, out or under consideration?

--- Exception Specification ---
The exception specification thread seemed very strongly in favour of including exception specification and that leaving it out was a bad idea. Walter - are you convinced?

--- Multiple Return Values from Functions ---
psheer introduced the idea of multiple return types for functions.  We've discussed possible syntax and a lot of positive comment has been made.  I've suggested that it's a much better idea that in, out and inout variables. Walter, what do you think?

Others?

Peter.

"kaffiene" <kaffiene@xtra.co.nz> wrote in message news:9ltg04$2361$1@digitaldaemon.com...
> This newsgroup has been extremely interesting so far - there have been a
lot
> of very interesting discussions.  What I'm wondering now is how the open issues will move towards resolution?  And, as a precursor to that discussion, what is the list of actual open issues?  What is in for sure, and what is on the maybe list?
>
> Personally, I'm very interested in seeing the resolution to some of the issues that have been raised.  To this end, I'd like to get Walter's feedback on some of the big issues that have been well debated - where are the issues going?  Are you considering adding some new elements that
weren't
> in the original spec?  Reconsidering old ones?
>
> Here are some of the major issues I'd like Walter to comment on:
>
> --- Generics ---
> I take it from Walter's posts and from the general sentiment, that some
form
> of Generics is desirable - are there any candidates looking at all likely?
>
> --- Operator Overloading ---
> Well, we've had quite a bun fight over operator overloading. ;-)  Is it
in,
> out or under consideration?
>
> --- Exception Specification ---
> The exception specification thread seemed very strongly in favour of including exception specification and that leaving it out was a bad idea. Walter - are you convinced?
>
> --- Multiple Return Values from Functions ---
> psheer introduced the idea of multiple return types for functions.  We've discussed possible syntax and a lot of positive comment has been made.
I've
> suggested that it's a much better idea that in, out and inout variables. Walter, what do you think?
>
> Others?
>
> Peter.
>

Peter - Great idea.  Personally, I'm intrigued by this language and the discussions going on here that may influence its development.  I'd love to hear Walters "State of the Language" address.  :)

Another discussion that's been pretty active is the import format - stick with the original spec, or go towards a more Java-like import system that solves alot of the problems people have pointed out?

-Brady

kaffiene <kaffiene@xtra.co.nz> wrote in message news:9ltg04$2361$1@digitaldaemon.com...
> Others?

My personal interests are:
 - enum.stringrep property (returns the name of an enum as a string). I
can't tell you how often I have to have parallel arrays just for debugging
stupid enums. As Walter pointed out in the D spec, parallel arrays are
annoying (ie, forgetting to change one of them and then everything is
mismatched). And the beauty of the module system is that the strings never
need to be compiled into the resulting code unless they are used. Perfect
for debugging. Most of the ideas in the "super enums" thread were very good.

 - Some kind of templatey/#define thing. Is that what you meant by
"Generals"?

 - Some way to deal with hardware specific issues. little-endian and
big-endian built in types could be very useful for reading rigid file
formats using cross-platform code. Most non-x86 processors have instructions
for reading opposite-endian integers, so it doesn't even have to be horribly
inefficient. This could also be useful for talking to hardware.

 - Maybe a way to disable garbage collection for firmware code or some other
cirmcumstance when it would be innapropriate to have large delays for GC or
for code that needs really tight control of memory.

I've never been so intrigued by a language spec before. Theres something in the called out features of D so far that strikes a chord in me. Its like someone grouped together all the things about C that annoy me and fixed them. :-) I definitely want this to see the light of day.

-David
david @@@@@@ porkrind_org

kaffiene wrote in message <9ltg04$2361$1@digitaldaemon.com>...
>--- Generics ---
>I take it from Walter's posts and from the general sentiment, that some
form
>of Generics is desirable - are there any candidates looking at all likely?


I've been looking at the Ada way of doing templates. It looks in the same direction as I've been thinking.

>--- Operator Overloading ---
>Well, we've had quite a bun fight over operator overloading. ;-)  Is it in, out or under consideration?


Under consideration. I doubt it will make it into version 1.

>--- Exception Specification ---
>The exception specification thread seemed very strongly in favour of including exception specification and that leaving it out was a bad idea. Walter - are you convinced?


Not yet <g>.

>--- Multiple Return Values from Functions ---
>psheer introduced the idea of multiple return types for functions.  We've discussed possible syntax and a lot of positive comment has been made.
I've
>suggested that it's a much better idea that in, out and inout variables. Walter, what do you think?


A large reservation I have is that the syntax is too different from C. Tuple returns will take a lot of getting used to. BTW, some of my colleagues have been very adamant about the advantages of multiple return types <g>.

David Caldlwell wrote in message <9lvdlb$603$1@digitaldaemon.com>...
>I've never been so intrigued by a language spec before. Theres something in the called out features of D so far that strikes a chord in me. Its like someone grouped together all the things about C that annoy me and fixed them. :-) I definitely want this to see the light of day.


What sold me was taking some old C code I had, and hand translating it into D. It just *looked* so much better. You can see some bits of my experiments in:

    www.digitalmars.com/d/ctod.html
    www.digitalmars.com/d/cpptod.html
    www.digitalmars.com/d/pretod.html

Heck, D is the language I want to program in, so that's my incentive <g>.

"Walter" <walter@digitalmars.com> wrote in message news:9m2coh$1ve8$1@digitaldaemon.com...
>
> kaffiene wrote in message <9ltg04$2361$1@digitaldaemon.com>...
> >--- Generics ---
> >I take it from Walter's posts and from the general sentiment, that some
> form
> >of Generics is desirable - are there any candidates looking at all
likely?
>
>
> I've been looking at the Ada way of doing templates. It looks in the same direction as I've been thinking.

Okay.  I'm not very familiar with Ada.  Could you (or anyone else) expand on how Ada templates work?  I hate templates in C++, but I'm willing to be shown a better way ;-)


> >--- Operator Overloading ---
> >Well, we've had quite a bun fight over operator overloading. ;-)  Is it
in,
> >out or under consideration?
>
>
> Under consideration. I doubt it will make it into version 1.

OK.  We'll just continue throwing buns at each other, I guess ;-)

> >--- Exception Specification ---
> >The exception specification thread seemed very strongly in favour of including exception specification and that leaving it out was a bad idea. Walter - are you convinced?
>
> Not yet <g>.

OK.  I'm concerned that this probably needs to be either included or rejected as early in the evolution of D as possible.  As John Carney said in the Exception Specification thread:

"Think of it this way: if it is decided five years down the track that rigid exception specification is, after all, a good thing, you're going to break an awful lot of code if you try to tack it onto the language. On the other hand, if we in the pro-specification camp turn out to be wrong, then relaxing the rules isn't going to render anybody's code base inoperable."

(I'm biased - I think leaving this out would a huge loss)


> >--- Multiple Return Values from Functions ---
> >psheer introduced the idea of multiple return types for functions.  We've discussed possible syntax and a lot of positive comment has been made.
> I've
> >suggested that it's a much better idea that in, out and inout variables. Walter, what do you think?
>
>
> A large reservation I have is that the syntax is too different from C.
Tuple
> returns will take a lot of getting used to. BTW, some of my colleagues
have
> been very adamant about the advantages of multiple return types <g>.

So it's open for debate? ;-)

Point taken about the syntax, but I don't think it's *too* major.
You don't necessarily need tuples (as a language feature), just bind return
values to descrete variables.
Some of my colleagues were saying that having multiple return values from a
function would be a good enough reason to use the language (this is coming
from C++ zealots)

Cheers,

Peter.

Walter wrote:
> kaffiene wrote in message <9ltg04$2361$1@digitaldaemon.com>...
> 
>>--- Generics ---
>>I take it from Walter's posts and from the general sentiment, that some
>>
> form
> 
>>of Generics is desirable - are there any candidates looking at all likely?
>>
> 
> 
> I've been looking at the Ada way of doing templates. It looks in the same
> direction as I've been thinking.
> 
> 
>>--- Operator Overloading ---
>>Well, we've had quite a bun fight over operator overloading. ;-)  Is it in,
>>out or under consideration?
>>
> 
> 
> Under consideration. I doubt it will make it into version 1.
> 
Well, I'll hope for version 2 then.  :-)
> 
>>--- Exception Specification ---
>>The exception specification thread seemed very strongly in favour of
>>including exception specification and that leaving it out was a bad idea.
>>Walter - are you convinced?
>>
> 
> 
> Not yet <g>.
How do you see run-time contract violations as being handled?
The possibilities that occur to me are program termination (Ouch!) and exceptions (or Eiffel's Resume blocks).

Do you intend to include Resume blocks that can catch them?   I haven't been too pleased with how they work in Eiffel.  But, I suppose, that with in-out parameters one could frequently pass back an error code. The problem is that in a stream of function operations the error code wouldn't get processed until after the rest of the processing of the stream with invalid information had occured, so you better be able to figure out a harmless return value.  And I haven't always been able to.

Perhaps program termination is the soft option?
> 
...

I was reading the pages you put up.  Nice summary :)

However, there is a serious discrepancy between http://www.digitalmars.com/d/lex.html and http://www.digitalmars.com/d/ctod.html regarding escaped characters in strings.

lex.html says that strings in double-quotes include escape characters like C, while strings in single-quotes are taken as-is:

"deltree c:\\windows\n"
    is the same as
'detree c:\windows' \n

ctod.html says that strings in double-quotes cannot have escape characters.

"Charles Hixson" <charleshixsn@earthlink.net> wrote in message
> How do you see run-time contract violations as being handled?
> The possibilities that occur to me are program termination (Ouch!) and
> exceptions (or Eiffel's Resume blocks).

As throwing an exception.


> Do you intend to include Resume blocks that can catch them?   I haven't been too pleased with how they work in Eiffel.  But, I suppose, that with in-out parameters one could frequently pass back an error code. The problem is that in a stream of function operations the error code wouldn't get processed until after the rest of the processing of the stream with invalid information had occured, so you better be able to figure out a harmless return value.  And I haven't always been able to.

Exceptions would be caught by the usual catch() mechanism. If you don't catch them, they bubble up and terminate the program with an appropriate program.

> What sold me was taking some old C code I had, and hand translating it
into
> D. It just *looked* so much better. You can see some bits of my
experiments
> in:
>
>     www.digitalmars.com/d/ctod.html
>     www.digitalmars.com/d/cpptod.html
>     www.digitalmars.com/d/pretod.html
>
> Heck, D is the language I want to program in, so that's my incentive <g>.
>

Looking at those pages reaffirmed why I already wanted D to be a reality.

:)

-Brady