220 36428 <91e1487d-aff5-4b35-835c-58d71546572b@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: inkwizytoryankes@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: The current attribute/keyword dividing line is unsustainable. Date: Fri, 29 Dec 2017 10:00:59 -0800 (PST) Lines: 176 Approved: news@gmane.org Message-ID: <91e1487d-aff5-4b35-835c-58d71546572b@isocpp.org> References: <86919454-9af9-4b08-b7b3-fd262b46cdd5@isocpp.org> <094e32b8-2d97-43b0-a472-0e96752cd293@isocpp.org> <7141e0f8-e0d5-497e-b13b-77669e0520c5@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_27823_679545475.1514570459183" X-Trace: blaine.gmane.org 1514570344 31158 195.159.176.226 (29 Dec 2017 17:59:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 29 Dec 2017 17:59:04 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDDLTAGNTIBBBW4FTLJAKGQEWDCDFWA@isocpp.org Fri Dec 29 18:59:00 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f199.google.com ([209.85.217.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUyvq-0007c1-8U for gclcip-std-proposals@m.gmane.org; Fri, 29 Dec 2017 18:58:58 +0100 Original-Received: by mail-ua0-f199.google.com with SMTP id d7sf21405074uad.22 for ; Fri, 29 Dec 2017 10:01:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=37KYAF1WMZ96711Y10nihTzU8mHeDXvwUwb7nzKAou8=; b=JjACIExB5YyCnp218spCRreAZczkkfHdNUCZuA48AmvPUF68VshGXOuRwH3ruiG+jW Me5O8Sgsr03LY4gNFTgqNRDl8tdPeqKCvaR5fVLoakorFSRdFUbPh8tfsMpe2+Qpp6VX PX3PJPW3lBME8toV6tQbWoc9/GdLZWixJFh20ZTv0BsLlot/n/Maencb5glEDql09Tll Vc90hnEc1FzPBOepleLkDo6u3PiIdiLA48uOug8/SX9wI9875k9aaYpUum7qYqhVKXHa nkEU51nj5IOgulQRO4oeEP2idaUJx1SO7O1bCueMPDIR230J/Et+vlhxcoS6/t93O4qU fbkg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=37KYAF1WMZ96711Y10nihTzU8mHeDXvwUwb7nzKAou8=; b=eC/5XGZo0O9fMAede0gUJS/olNNQgug1HE2I/T6mxrsuElpzDhioxCFMuoZBINvoZF rI16++kGPXZgyJB8h/Yo+FrZsEk/WrxUA16+ATvwDTBac+ymzjzuvblCTlkzGZbAib3V 6pK7wPfNzTOoJwNHmNVD3f/KuyJDWChBy5t8+nw320IZVsfy8veeIhdj99uwl4GXoVgs rmQQxM7QEWa6pRUWQB08hoJeHY6VQhF9Mv8fkMVZOk3fk0LvhoSCx1bStaQN05tGOE1N oy/RFHBFRWBzA3Bv97Xj4RLQRpWKP3msVdpDmogEFc+QVjiuWOb274GnkkvhLvdrW1Pa PFOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=37KYAF1WMZ96711Y10nihTzU8mHeDXvwUwb7nzKAou8=; b=iqiLF7JBOV4TFYMq1J7VpEndDZIMl3axLQyI4SDTPpaaqI+Pz6JGqP1Ae/wPvLVkTl IJmmTPahdlTtY5+td6F+qHs4p/pGglviSfW2/XWpdv0k/FDbx3NoXklZCEsorGdAOrFT sX/vadElXDa9mETark6YBONwoheHSZhdUOry0zHZryu7TLppOasIlI+e09foUuUR+8+h fkmjGnYMokFhP3OtRLhNsqpNoByKSvQzqD0s/5btuxEwL9wS0dOndNClc9PS5iYIRU+5 OUwzKsydNDAkCyboP298Gzu6r2R5uATBZcB6N2GFDoXM8hkapRqc8OXRCp4Jv5B+F9iE cpFQ== X-Gm-Message-State: AKGB3mLWSg6xBicR5wun2Xw/LrfUPk/uqbgieuMZCbFfZb1Qpl8+4Jjw RJBPyGXRmaXSi5MRf7fsCczoNg== X-Google-Smtp-Source: ACJfBot52Sz1BeqCUnQ+koyORleFR5vcmU7hmniLO3EKk9UFYiYHlMMdGVK4DKiOxwYLVoytMA1o2A== X-Received: by 10.176.79.161 with SMTP id m33mr15285727uah.18.1514570460917; Fri, 29 Dec 2017 10:01:00 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.5.170 with SMTP id e39ls2922850uae.15.gmail; Fri, 29 Dec 2017 10:00:59 -0800 (PST) X-Received: by 10.31.162.68 with SMTP id l65mr1821044vke.12.1514570459638; Fri, 29 Dec 2017 10:00:59 -0800 (PST) In-Reply-To: <7141e0f8-e0d5-497e-b13b-77669e0520c5@isocpp.org> X-Original-Sender: inkwizytoryankes@gmail.com 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:36428 Archived-At: ------=_Part_27823_679545475.1514570459183 Content-Type: multipart/alternative; boundary="----=_Part_27824_1411240351.1514570459183" ------=_Part_27824_1411240351.1514570459183 Content-Type: text/plain; charset="UTF-8" On Friday, December 29, 2017 at 9:26:39 AM UTC+1, mihailn...@gmail.com wrote: > > ... > >> In case of `[[no_unique_address]]` we could forbid taking address or >> offset of member, then you could not detect if some object have same >> address. Only problem would be it will be hard to enforce and check in >> compile time (some member function of this member could take address). >> >> >> > The problem with [[no_unique_address]] has nothing to do with addresses, > but the fact, given this code: > > struct Alloc {}; > > template > struct cool_boy > { > [[no_unique_address]] Allocator alloc; > }; > > This user code will fail to compile if the attr is ignored. > > struct innocent_use > { > template>> > innocent_use(Cool&&) { } > }; > > innocent_use use{cool_boy{}}; > > "Or worse" if another overload is present. > > > Of corse, this why I said couple lines before "should only affect size and address of member, nothing more". -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/91e1487d-aff5-4b35-835c-58d71546572b%40isocpp.org. ------=_Part_27824_1411240351.1514570459183 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Friday, December 29, 2017 at 9:26:39 AM UTC+1, = mihailn...@gmail.com wrote:
...=C2=A0
In case of `[[no_unique_address]]` we could forbid = taking address or offset of member, then you could not detect if some objec= t have same address. Only problem would be it will be hard to enforce and c= heck in compile time (some member function of this member could take addres= s).



The = problem with=C2=A0=C2=A0[[no_unique_address]] has nothing to do with addresses, but th= e fact, given this code:

struct Alloc {};

template<typename Allocator=3DAlloc>
st= ruct cool_boy
{
=C2=A0 [[no_unique_address]] Allocator allo= c;
};

This user code will fail to compile if the attr is i= gnored.

struct innocent_use
{=C2=A0 template<class Cool, template =3D std::enable_if_t<std::is_<= wbr>empty_v<Cool>>>
=C2=A0 innocent_use(Cool&&) { }<= br>};

innocent_use use= {cool_boy{}};

"Or worse" if another overload is present.=C2=A0
=

=C2=A0
Of corse, this why I said couple = lines before "should only affect size and address of member, nothing m= ore".

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/91e1487d-aff5-4b35-835c-58d71546572b= %40isocpp.org.
------=_Part_27824_1411240351.1514570459183-- ------=_Part_27823_679545475.1514570459183-- .