Kevin Bealer wrote:

> In article <c8o52s$1j0l$1@digitaldaemon.com>, Benedikt Meurer says...
>>
>>Hello,
>>
>>Would it be possible to add support for void returns, as in
>>
>>void f1 () { ... }
>>void f2 () { ...; return f1 (); }
>>
>>to D? This would be invaluably helpful in template programming. Else one has to either make heavy use of mixins or write a lot of specialisations.
>>
>>(Looking at the code, it seems, that only dmd/statement.c has to be
>>modified to archive this goal).
> 
> 
> This idea could be taken further.  Instead of just for return types, imagine something like this:
> 
> void[int] set_of_int;
> 
> Now, I have a set.  The object is a map (assoc. array) but a map with no key is a set.  I would need some way to determine if an element is present of course.

You probably want to say "A map with no *data*"

Since the bool type suggestion went down so well, it's worth pointing out that the keyword "void" is also similarly overloaded to mean two completely different things - and this is also true in C, C++ and Java.

"void" on its own means "nothing". A function which returns void, is a function which does not return a value at all.

On the other hand, "void *" does NOT mean "pointer to nothing". It means "pointer to ANYTHING". And there is a big, big difference in meaning between "nothing" and "anything".

Imagine if, instead of the single type void, we had two types: "void" and "unknown". Throughout the universe of D, all instances of "void *" would be changed to "unknown *". unknown.sizeof would be defined to be equal to 1, but "void.sizeof" would be defined to be equal to 0. Functions would be allowed to return void, but it would be illegal to return unknown (but perfectly ok to return a POINTER to unknown). A "variable" could be declared as being of type void (but not unknown). Such a void variable would occupy zero bytes of storage, but it would still be possible to take its address. An array like void[100000000] would be possible, and would still occupy zero bytes. (And yes, this would be useful - at least, in generic template programming).

"unknown", on the other hand would be less flexible. Only "unknown *" would be allowed. Such a pointer may never be dereferenced, without first being cast into something else.

Of course, I don't expect anyone either to take this seriously, or to implement this. But I just bring this to people's attention - (void *) does not mean "pointer to void", it means "pointer to something but we don't know what it is". And this can sometimes cause confusion.

Arcane Jill

I'm for it.

In article <c91ipc$10lq$1@digitaldaemon.com>, Arcane Jill says...
>
>Since the bool type suggestion went down so well, it's worth pointing out that the keyword "void" is also similarly overloaded to mean two completely different things - and this is also true in C, C++ and Java.
>
>"void" on its own means "nothing". A function which returns void, is a function which does not return a value at all.
>
>On the other hand, "void *" does NOT mean "pointer to nothing". It means "pointer to ANYTHING". And there is a big, big difference in meaning between "nothing" and "anything".
>
>Imagine if, instead of the single type void, we had two types: "void" and "unknown". Throughout the universe of D, all instances of "void *" would be changed to "unknown *". unknown.sizeof would be defined to be equal to 1, but "void.sizeof" would be defined to be equal to 0. Functions would be allowed to return void, but it would be illegal to return unknown (but perfectly ok to return a POINTER to unknown). A "variable" could be declared as being of type void (but not unknown). Such a void variable would occupy zero bytes of storage, but it would still be possible to take its address. An array like void[100000000] would be possible, and would still occupy zero bytes. (And yes, this would be useful - at least, in generic template programming).
>
>"unknown", on the other hand would be less flexible. Only "unknown *" would be allowed. Such a pointer may never be dereferenced, without first being cast into something else.
>
>Of course, I don't expect anyone either to take this seriously, or to implement this. But I just bring this to people's attention - (void *) does not mean "pointer to void", it means "pointer to something but we don't know what it is". And this can sometimes cause confusion.
>
>Arcane Jill
>
>

Intersting idea..

Q: why type "unknown *" when we could just type "unknown"?

basically the type "unknown" could be defined as a pointer to anything, so assigning anything to an unknown automatically takes it's address.


On Wed, 26 May 2004 07:59:40 +0000 (UTC), Arcane Jill <Arcane_member@pathlink.com> wrote:
> Since the bool type suggestion went down so well, it's worth pointing out that
> the keyword "void" is also similarly overloaded to mean two completely different
> things - and this is also true in C, C++ and Java.
>
> "void" on its own means "nothing". A function which returns void, is a function
> which does not return a value at all.
>
> On the other hand, "void *" does NOT mean "pointer to nothing". It means
> "pointer to ANYTHING". And there is a big, big difference in meaning between
> "nothing" and "anything".
>
> Imagine if, instead of the single type void, we had two types: "void" and
> "unknown". Throughout the universe of D, all instances of "void *" would be
> changed to "unknown *". unknown.sizeof would be defined to be equal to 1, but
> "void.sizeof" would be defined to be equal to 0. Functions would be allowed to
> return void, but it would be illegal to return unknown (but perfectly ok to
> return a POINTER to unknown). A "variable" could be declared as being of type
> void (but not unknown). Such a void variable would occupy zero bytes of storage,
> but it would still be possible to take its address. An array like
> void[100000000] would be possible, and would still occupy zero bytes. (And yes,
> this would be useful - at least, in generic template programming).
>
> "unknown", on the other hand would be less flexible. Only "unknown *" would be
> allowed. Such a pointer may never be dereferenced, without first being cast into
> something else.
>
> Of course, I don't expect anyone either to take this seriously, or to implement
> this. But I just bring this to people's attention - (void *) does not mean
> "pointer to void", it means "pointer to something but we don't know what it is".
> And this can sometimes cause confusion.
>
> Arcane Jill
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Wed, 26 May 2004 07:59:40 +0000 (UTC), Arcane Jill wrote:

> Since the bool type suggestion went down so well, it's worth pointing out that the keyword "void" is also similarly overloaded to mean two completely different things - and this is also true in C, C++ and Java.
> 
> "void" on its own means "nothing". A function which returns void, is a function which does not return a value at all.
> 
> On the other hand, "void *" does NOT mean "pointer to nothing". It means "pointer to ANYTHING". And there is a big, big difference in meaning between "nothing" and "anything".
> 
> Imagine if, instead of the single type void, we had two types: "void" and "unknown". Throughout the universe of D, all instances of "void *" would be changed to "unknown *". unknown.sizeof would be defined to be equal to 1, but "void.sizeof" would be defined to be equal to 0. Functions would be allowed to return void, but it would be illegal to return unknown (but perfectly ok to return a POINTER to unknown). A "variable" could be declared as being of type void (but not unknown). Such a void variable would occupy zero bytes of storage, but it would still be possible to take its address. An array like void[100000000] would be possible, and would still occupy zero bytes. (And yes, this would be useful - at least, in generic template programming).
> 
> "unknown", on the other hand would be less flexible. Only "unknown *" would be allowed. Such a pointer may never be dereferenced, without first being cast into something else.
> 
> Of course, I don't expect anyone either to take this seriously, or to implement this. But I just bring this to people's attention - (void *) does not mean "pointer to void", it means "pointer to something but we don't know what it is". And this can sometimes cause confusion.
> 
> Arcane Jill

Hmmmmm...don't know....sounds a bit too logical... Oh well, let's throw caution to the wind. I think this is a Good Idea (tm).

Let's see now...

  unknown *X;
  int A;
  int B;

  X = &A;  // Now X points to A

  B = cast(int)*X; // Assign B to whatever X points to ('A' in this case)

-- 
Derek
27/May/04 10:00:26 AM

In article <c8omac$2bc9$1@digitaldaemon.com>, Matthew says... .
>Here's another one to consider. In C++ I've had occasion to require a
>sizeof(void), and had to resort to traits in order to get it. Does anyone see a
>downside with sizeof(void) being legal in D?
>

There would discussion, then arguments, then terrible war between the proponents of "void.size==" 0, 1, and 4.  So essentially, no.

Kevin

"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:c93rtk$1bic$1@digitaldaemon.com...
> In article <c8omac$2bc9$1@digitaldaemon.com>, Matthew says... .
> >Here's another one to consider. In C++ I've had occasion to require a sizeof(void), and had to resort to traits in order to get it. Does anyone see
a
> >downside with sizeof(void) being legal in D?
> >
>
> There would discussion, then arguments, then terrible war between the
proponents
> of "void.size==" 0, 1, and 4.  So essentially, no.

Yup, if there could not be 99.98% consensus, then I agree the idea must die.

I'll just have to have a size_traits in DTL like I've got in STLSoft. ;)

In article <c91ipc$10lq$1@digitaldaemon.com>, Arcane Jill wrote:
> On the other hand, "void *" does NOT mean "pointer to nothing". It means "pointer to ANYTHING". And there is a big, big difference in meaning between "nothing" and "anything".
> 
> Imagine if, instead of the single type void, we had two types: "void" and "unknown". Throughout the universe of D, all instances of "void *" would be changed to "unknown *". unknown.sizeof would be defined to be equal to 1, but "void.sizeof" would be defined to be equal to 0. Functions would be allowed to return void, but it would be illegal to return unknown (but perfectly ok to return a POINTER to unknown). A "variable" could be declared as being of type

Why not use just byte* instead of unknown*?

Because in the end every pointer *is* a pointer to a byte, and that's about as little semantics as you can give to a pointer to anything.

I know - safety issues I guess, to prevent accidental use of those pointers?

(I like the idea of void as something of size 0)

-Antti

-- 
I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.

In article <c940h3$1i62$1@digitaldaemon.com>, Matthew says...
>
>
>"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:c93rtk$1bic$1@digitaldaemon.com...
>> In article <c8omac$2bc9$1@digitaldaemon.com>, Matthew says... .
>> >Here's another one to consider. In C++ I've had occasion to require a sizeof(void), and had to resort to traits in order to get it. Does anyone see
>a
>> >downside with sizeof(void) being legal in D?
>> >
>>
>> There would discussion, then arguments, then terrible war between the
>proponents
>> of "void.size==" 0, 1, and 4.  So essentially, no.
>
>Yup, if there could not be 99.98% consensus, then I agree the idea must die.
>
>I'll just have to have a size_traits in DTL like I've got in STLSoft. ;)

Actually, I meant, that usenet's natural state is endless war, so there's no downside.

Maybe the classes which want void.size really should be broken.  If you can't get around needing the size then you probably have a bug right?  I mean, unless it is just a printf().  I think if there was void.sizeof there would be people arguing that it should be illegal, in the same spirit as bit == bool.

Kevin

>Maybe the classes which want void.size really should be broken.  If you can't get around needing the size then you probably have a bug right?  I mean, unless it is just a printf().  I think if there was void.sizeof there would be people arguing that it should be illegal, in the same spirit as bit == bool.
>
>Kevin


Actually, that is a very good point. If void.sizeof were simply *not defined* then you'd HAVE to cast it to something else before trying to do pointer arithmetic with it.

I still like the idea of having some kind of type with zero size though. So that:
>
>       zero_size_thing x;          // legal
>       zero_size_thing* p, q, r;   // legal
>       zero_size_thing[1000000000] a;
>                             // is also legal, and takes no memory
>       x.sizeof              // equals zero
>       a.sizeof              // equals zero
>       p = a;                // legal
>       q = &a[100];          // legal
>       q = &a[1000000001];   // NOT legal - array bounds exception
>       r = &x;               // legal
>       (p == q)              // returns true
>       (p == r)              // returns false
>       (a[0] == x)           // returns true, since all zero sized objects are equal
>       return x;             // identical in meaning to return;

I'm not hung up on this one. I don't care one way or the other whether sizeof void is 0, 1, or undefined. I don't care if we split void into its two separate meanings (zero_size_thing and unknown) or not. But in my own little way I like to speculate about such ideas, and if they turn out to be useful, fair play. If not, it's no big deal. I've made other suggestions which matter more to me, but this thread I just regard as fun.

Incidently, I accidently parsed "void returns" in the same way as "Batman Returns". I thought: does it?

Jill