> Moreover, this is how the ABI (at least x86) works: a 1-tuple return is
> stored (typically) in the EAX register. A 0-tuple return does not store
> anything (contents of EAX are unspecified).

Actually, void, as it currently stores unspecified contents in EAX, means just
that returned value doesn't contain any interpretable information. It stands
for "this function returns, but the returned value isn't useful".

I am in favour of void being a unit type. In my opinion, the void type should
denote a value, which doesn't contain observable information. That is, it's
set of values is not empty.

This is to be able to say that the value-set of an aggregate type is just a
Cartesian product of the value-sets of its members. Pretty much what you guys
when when saying x * 1 = x.
This also allows for the compiler to optimize out the storage for a value of
type void, because unobservable information can't change the observed behaviour
of the program.

> *RIGHT NOW*, 'void' is used to indicate the absence of a value - i.e.
> Basically, a void value is just ignored

You are contradicting yourself here, an absent value can't be ignored, it's
just not there.

Expanding a little bit further:

Saying that the value of a void can't be observed (or is undetermined), etc....
empowers us to do some pretty things with it.

First of all, it was mentioned that taking the address of a void should return
NULL. I oppose, because this would mean that

void ar[2];

&ar[0] == &[1]; // returns true
&ar[0] == ar; // return false

This appears to be a bit unhandy to handle because it breaks identity compares.
It would be best to assign an address to void where needed. This also opposes
my (earlier) idea of sizeof(void) == 0. I'd advocate sizeof(void) >= 1 here,
to give a little more freedom and don't break more than we need - hopefully nothing.


The most concerns have been raised about

void foo();
void foo(void) {/* implementation */}

In this case I'd say that foo() and foo(void) both define two overloads of foo,
specifically the no-args version and the with-argument-version. There's no way we
can change this without breaking huge bits of code out there.

This implies that

template<typename T>
void log_something(T a);

log_something(); // Okay, T=void

Note that I don't mean to change to meaning of l-value references in the context of void.

void bar(void&);
bar(); // Illegal, must hand over void

but I like the idea that "emptyness" represents no information and is convertible to
undetermined information, thus making the absence of tokens convertible to an expression
resulting in void. This makes all of the following possible:

void foo(void&&);
foo(); // Ok, expression resulting in void bound to r-value reference

template<typename T>
struct Future {
   void set_value(T const&);
};
Future<void>{}.set_value();

void foo() {
   return; // No tokens, converted to an expression of type void
   // This continues to work as it should
}

I want to highlight the last example, where "an absence of tokens" between the return and
the ; is converted to an expression of void. The only special rule we'd have to further
analyse is that when a void method doesn't return, void is returned implicitly.
I though believe that it is possible to make the needed changes with ease.

This wording doesn't only specifically allow calling a function with a void-argument with-
out providing a value, it also disallows fully omitting a void argument in any other case.
I'm hugely in favour of that, else we'd have to fiddle with overloads and perhaps change
a whole lot, whereas a bit of verbosity (as tiny as a comma would seem) doesn't hurt.

void foo(int, void);
foo(3); // Illegal, no overload for foo(int)
foo(3,); // Legal, foo(int, <expression resulting in void>)

- WE

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-08-07 19:44, Martin Molzer wrote:
>> *RIGHT NOW*, 'void' is used to indicate the absence of a value - i.e.
>> Basically, a void value is just ignored
>
> You are contradicting yourself here, an absent value can't be ignored, it's
> just not there.

Fine; "value" in the second sentence should have been in quotes.

As in:

  void bar();
  void foo()
  {
    return bar(); // the "value" here is ignored
  }

> The only special rule we'd have to further analyse is that when a
> void method doesn't return, void is returned implicitly.

Not really; this code is already legal:

  int foo()
  {
  }

(Results in UB, maybe, but legal. Which is absurd, if you ask me, but...)

So there is no "need" for such a special rule unless we fix that
non-void functions aren't required to explicitly return either. Anyway,
since the void case does not produce a meaningful value, the UB is
irrelevant for that case.

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.