I hope some of these are useful:::

1.
A major limitation of C code is not being able to return
more than one argument from a function. For instance,
the stack would easily be able to handle functions like:
	int, float, char* foo ()
	{
		return 1, 3.1416, "pi";
	}
which is preferable to
	int foo (float *result1, char **reault2)
	{
		*result1 = 3.1416;
		*result2 = "pi";
		return 1;
	}
(or evan preferable to declaring an intermediate struct)
This notation reduces code size enormously. Then (like python):
	int r;
	float val;
	char *descr:
	r, val, descr = foo ();


2.
"there appears to be practically no other use for __FILE__ and __LINE__"

These can be passed to functions to get tracebacks. I hope D is not considering dropping them as they are essential IMO.

3.
I think that source files should be only UTF8 because:
	- UTF8 supports 20 bit characters.
	- UTF8 is exactly ASCII when there are no
		international characters (the usual case).
	- Its better to have only one format

4. A D to C translator?

5. "if a new errno value is added to the runtime system, the old code can not properly display a meaningful error message"

This is scarcely true: strerror() ???


-paul

-- 
Paul Sheer Consulting IT Services . . . Tel . . . +27 21 761 7224 Linux development, cryptography,  recuitment,  support,  training http://www.icon.co.za/~psheer . . . . http://rute.sourceforge.net L I N U X . . . . . . . . . . . .  The Choice of a GNU Generation

"psheer AT icon DOT co DOT za" <nospam@nospam.com> wrote in message news:9llhvs$d42$1@digitaldaemon.com...
>
> I hope some of these are useful:::
>
> 1.
> A major limitation of C code is not being able to return
> more than one argument from a function. For instance,
> the stack would easily be able to handle functions like:
> int, float, char* foo ()
> {
> return 1, 3.1416, "pi";
> }
> which is preferable to
> int foo (float *result1, char **reault2)
> {
> *result1 = 3.1416;
> *result2 = "pi";
> return 1;
> }
> (or evan preferable to declaring an intermediate struct)
> This notation reduces code size enormously. Then (like python):
> int r;
> float val;
> char *descr:
> r, val, descr = foo ();
>


Agreed.  I think this is a much better idea than in, out and inout parameters.  Given something like this:

int a,b,x;
a,b = myfunc(x);

it's obvious the role that a,b and x play, whereas with in, out & inout the call looks like:

int a,b,x;
myfunc(a,b,x);   // or a = myfunc(b,x);

This is definitely an improvement over the current D spec.

Peter.

> I think this is a much better idea than in, out and inout
> parameters.  Given something like this:
> int a,b,x;
> a,b = myfunc(x);
> it's obvious the role that a,b and x play

While multiple return parameters seem elegant, you end up with code that is harder to read and maintain.  Consider

  int,int,int,int CountAnimals();

which is called

  numCats,numDogs,numFerrets,numGoats = CountAnimals();

Without parameter names attached to the output values in the declaration, it's hard to know if I've picked up the return values correctly.

Greg Robbins

Grobbins wrote:

> While multiple return parameters seem elegant, you end up with code that is harder to read and maintain.  Consider
>
>   int,int,int,int CountAnimals();
>
> which is called
>
>   numCats,numDogs,numFerrets,numGoats = CountAnimals();
>
> Without parameter names attached to the output values in the declaration, it's hard to know if I've picked up the return values correctly.

Right.  It is possible (though ugly) to return structures or classes which are aggregates of your various return types.  I do hope that D (unlike C) will allow you to return an array (don't see in the spec if it defines if you can or not).  This would make a lot of sense with the self-awareness that D arrays have.

Consider these possible declarations:

int[] foo();   // returns an array of ints, unknown size
int[3] foo();   // returns an array of ints, guaranteed to be 3 long.  might
throw an exception if function tried to return something else

Russ Lewis wrote in message <3B7EE227.D011607E@deming-os.org>...
>I do hope that D (unlike C)
>will allow you to return an array (don't see in the spec if it defines if
>you can or not).  This would make a lot of sense with the self-awareness
>that D arrays have.


Yes, it works in D.

>Consider these possible declarations:
>
>int[] foo();   // returns an array of ints, unknown size


Yes.

>int[3] foo();   // returns an array of ints, guaranteed to be 3 long.
might
>throw an exception if function tried to return something else


I hadn't thought of that case.

> >int[3] foo();   // returns an array of ints, guaranteed to be 3 long.
> might
> >throw an exception if function tried to return something else
>
>
> I hadn't thought of that case.
>
This one doesn't seem reasonable to me.  Maybe it's just how I'm looking at it, but it seems to me if a function returns an integer, you should place a restriction on what range of integer it returns.  If it returns a unicode character, you shouldn't limit it to ascii characters.  If it returns a "fooObject", you shouldn't limit it to a "fooObject" with various data members.

If it returns an integer array, you shouldn't limit the parameters of the array you get back.

Especially since D's arrays have that WONDERFULLY useful extra information coded in such as array length, I say return a generic integer array, and if the function caller needs it to be of length 3, it's easy enough for them to check it via int[].length.

I don't know what specifically about this bothers me, but for some reason I
shudder whenever I think about it.  Almost like "boolean foo(){ return
true; }" being declared as "true foo(){ return; }" or "true foo(){ return
true; }"

That's just my two cents.  Any other thoughts?

-Brady

"Grobbins" <grobbins@badaddress.znet.com> wrote in message news:grobbins-2176AA.11503918082001@news.digitalmars.com...
> > I think this is a much better idea than in, out and inout
> > parameters.  Given something like this:
> > int a,b,x;
> > a,b = myfunc(x);
> > it's obvious the role that a,b and x play
>
> While multiple return parameters seem elegant, you end up with code that is harder to read and maintain.  Consider
>
>   int,int,int,int CountAnimals();
>
> which is called
>
>   numCats,numDogs,numFerrets,numGoats = CountAnimals();
>
> Without parameter names attached to the output values in the declaration, it's hard to know if I've picked up the return values correctly.

Okay, that's a fair point. I can think of a couple of declaration formats that might fix that issue:

(int cats, int dogs, int ferrets, int goats) countAnimals()
{
    ...
}

or

countAnimals() returns (int cats, int dogs, int ferrets, int goats)
{
    ....
}


I prefer the latter.  Anyone else really like it?  Hate it?

I still think that in:

    a,b = myfunc(x);

It is much clearer what role the variables are taking as input or results from the function as compared to the in, out, inout approach.


Peter.

> countAnimals() returns (int cats, int dogs, int ferrets, int goats)
> {
>     ....
> }
>
>
> I prefer the latter.  Anyone else really like it?  Hate it?


That is intriguing.  Definately clear, and it could be reasonably useful.  I have a couple of nitpicks, one major and one minor.  Major - what is the formal return type of this function?  I notice you just wrote - countAnimals() returns (int.......goats)

there is nothing before the function name.  Granted, the return type is implicitly 4 integers, but I think one of the things (possibly) holding this feature back is that 4 integers is neither a primitive data type, nor a class/struct/union type.  It's just.... 4... different primitive data types. If you can give a formal, simple definition as to the return type of the function, it may be worth looking into and could end up being something incredibly useful.  ;)

The minor nitpick - A number of ways to do this just ran through my head, but I noticed you haven't touched on the point at all - what is the syntax of return the values within the function?

I'm sure you're thinking something as simple as "return
(cats,dogs,ferrets,goats);" but, of course, that may also not be as simple
as it seems....  ;)

-Brady

Bradeeoh wrote:

> If it returns an integer array, you shouldn't limit the parameters of the array you get back.
>
> Especially since D's arrays have that WONDERFULLY useful extra information coded in such as array length, I say return a generic integer array, and if the function caller needs it to be of length 3, it's easy enough for them to check it via int[].length.
>
> I don't know what specifically about this bothers me, but for some reason I
> shudder whenever I think about it.  Almost like "boolean foo(){ return
> true; }" being declared as "true foo(){ return; }" or "true foo(){ return
> true; }"

In my view, it's a design distinction between "return an array of values" (that
might have any number of values) and "return three integers".  Consider a new
strtoul():

int[2] strtoul(char *str,int base)

In this D implementation, return[0] returns the value you wanted, and return[1] is analogous to the endPtr parameter of C's strtoul.  In this case, return[1] will return how many characters were consumed.  It would not make any sense, in this function, to return any more or less than 2 values.

>
> In my view, it's a design distinction between "return an array of values"
(that
> might have any number of values) and "return three integers".  Consider a
new
> strtoul():
>
> int[2] strtoul(char *str,int base)
>
> In this D implementation, return[0] returns the value you wanted, and
return[1]
> is analogous to the endPtr parameter of C's strtoul.  In this case,
return[1]
> will return how many characters were consumed.  It would not make any
sense, in
> this function, to return any more or less than 2 values.
>

Point taken, however, I'm still not convinced that an array of length 2 of integers should be treated any differently than a general array of integers.

Another way of describing my problem with it is this - if you're going to allow functions to return int[2], then are you also going to allow these returned values to be stored in a var referencing a dynamic array?  A few problems possibly come to mind.

ie -

int[2] a;    // creates a static array analogous to c arrays
a = strtoul( char *str, int base );  // valid, since we're storing an int[2]
in an int[2].....?

int[] b;   // creates a dynamic array, with length data and is garbage
collectable
b = strtoul( char *str, int base );  // valid?  b is an int[], not an
int[2] - is this okay?

int[4] c;
c = strtoul( char *str, int base );  //  error?  or no?  whose to say?

I guess, what I'm trying to say, is that this type of return value would, in effect, be introducing a (near) infinite number of array types that may or may not have to be type checked to keep in the spirit of the language. Seems like implementing this would either cause us to A - require an extended, rigid semantic definition of how all this works and B - extra work in the compiler dealing with the basic possibilities.

-Brady