220 19729 <55C542D7.5090500@gmx.de> article Path: news.gmane.org!not-for-mail From: Martin Molzer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: *** GMX Spamverdacht *** Re: Allow values of void Date: Sat, 08 Aug 2015 01:44:23 +0200 Lines: 107 Approved: news@gmane.org Message-ID: <55C542D7.5090500@gmx.de> References: <4159b2c4-c03b-4086-9f71-fd5f78a4175c@isocpp.org> <0c973057-a1f2-485d-b8f4-8e0a7a641221@isocpp.org> <1549494.1QHixDtzqm@tjmaciei-mobl4> <6b885185-4217-40b4-a8cf-aa3591a655d4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed X-Trace: ger.gmane.org 1438991089 1081 80.91.229.3 (7 Aug 2015 23:44:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Aug 2015 23:44:49 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDKIXBXFVUEBBZUFSWXAKGQE3RKLE2I@isocpp.org Sat Aug 08 01:44:40 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f198.google.com ([209.85.212.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZNrJY-0001qw-FJ for gclcip-std-proposals@m.gmane.org; Sat, 08 Aug 2015 01:44:40 +0200 Original-Received: by wijp15 with SMTP id p15sf21832759wij.3 for ; Fri, 07 Aug 2015 16:44:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=ypJNfVGFSB46ZLLdDbbLYuyCgoDdYX4qA0zr01CHNU8=; b=HHJcXjMO0NbnlCzxm/weZGyH0EAcWZjiKLwqz9B5oLWJ72Z2ESTB0hbMJTa27yvWVp PdBSIZGoXH+xnmj/Ca4XOUjIDTYnx+eMdxJUrHumXBE8y3K8hMO9S9cPKIKrbTyY6hwa aaKJ785aB/uXAIZUluQ0e9ZeTVmkV7sU3vt2PnzX1yQGeNxt9/zriBXk0HUv/uCi0QZO 7eM2V5QO5a8QIGkzc59M+hPPpZH8WrVSg5qxxfdaxiVoc80tWf7DPflw7h7TAF1+5blk 3F6bGOAGExNNTUPnk2ZdSRmSjV8gqWO0c1qFPr4RMuWBZsepXrGes+IrXP5MUr/7dWJ2 HVvQ= X-Gm-Message-State: ALoCoQkxioVZC4aPHkICD+xgyg5QMNFgjn4+g33zcz+N2kWxYEpxMTlhIx005bZ5iSzrr59utyj/ X-Received: by 10.180.12.205 with SMTP id a13mr205146wic.4.1438991079692; Fri, 07 Aug 2015 16:44:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.89.140 with SMTP id bo12ls388974wib.14.canary; Fri, 07 Aug 2015 16:44:38 -0700 (PDT) X-Received: by 10.180.109.161 with SMTP id ht1mr1492395wib.10.1438991078437; Fri, 07 Aug 2015 16:44:38 -0700 (PDT) Original-Received: from mout.gmx.net (mout.gmx.net. [212.227.17.22]) by mx.google.com with ESMTPS id wb6si9604801wjc.121.2015.08.07.16.44.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Aug 2015 16:44:38 -0700 (PDT) Received-SPF: pass (google.com: domain of martin.molzer@gmx.de designates 212.227.17.22 as permitted sender) client-ip=212.227.17.22; Original-Received: from [192.168.178.26] ([77.47.109.202]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MACmL-1ZYcwe3gEr-00BPTZ for ; Sat, 08 Aug 2015 01:44:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: X-Provags-ID: V03:K0:5qo6DLkCvp7Z0H3OyWs5aoxMWsXQbNEMmTnJxidK9+x/sU4NONr y3wa79wg75wc+5Z0kwHZTTc1RJy92a4Q6t7Z0afjwRijspmfPcaaki8tnmd+kcd3Lsf3v3k 6SNoWCRYkYTS4MrAuGDkr68UETMSDaEieaFsZXf0Lfz69t1mt7Pid+n6+EjXwRPs6bcLEJM PYihHSWY+2XKXM6feF1aA== X-UI-Out-Filterresults: notjunk:1;V01:K0:u8/3OnsBXqA=:J7PmAHdIsqxeb+evi5T0Hj mB73VlU5uJhDv8KS+QMy3+DnjPe5b3Z2roA/smI4SISRuAxudJysEpbRWYP81amLmhvVOD2uq gkYG6pCEVDjjWcWOr1BrVtbvytgG3g/zeZlSuLM+TIffxM9MqF0w0CNCZCocPwyvnljCgXA2J UCh4JGF/Iu8OmApDVuo4jvA46gEy2tDqYw/hNFoTwxqcpdUsMdJ3tpqZLh+JZvrhNcSYGyk9x dmck3rMH2rKspu1fFqIe1X7PiwtJfP65ryeLU/BeO3Kp+sF0cfBVyWSrlCALh7aXryH5J+wUS 8Ud6RfqQRbW8NfKcB6U+CqK+GGcnXUgYYypbY6vA0Mm9Z26xnlwBcaUTjYd5hw0mDGHXLBq3S QZ6cxMcCB/x+qzxTvdtm0DrjuGDYgMi6oj6o+jhVKchmOLj3OHSY0jKqQ+mqFJHOrXFym379n DFK9g95gnfz0OFAsiqYWa51Hd5L10ZmmBQiIE1RbRjJBjo35cEV6PeSGYEuWlHoKHV4cDlNxw +0hljqTpaTk0hk4yCXjk4Xg/QmL8/JYpIXBg963ZR8YUhzyS8HaEPnz9Jb0jxOp647WSjR7rO ukn6jPH2K1Gp10H1oi7a3MIRgCCWc2P9w/5C2vVzK8kH6pZEmU09oWTojSJdJ2T72w8jthOTI pfepZZwbyvTj30LD0cHnyPRoF28eye/9VpMKiy+8ZyQl1cGR00adaBIYydVaL5TOZzCUU12XX O9XfNHsIx/76eUNpdK/sB53YQ2/ne12y5fmppQ== X-Original-Sender: martin.molzer@gmx.de X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of martin.molzer@gmx.de designates 212.227.17.22 as permitted sender) smtp.mail=martin.molzer@gmx.de Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:19729 Archived-At: > 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 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 struct Future { void set_value(T const&); }; Future{}.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, ) - 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/. .