220 33775 article Path: news.gmane.org!.POSTED!not-for-mail From: Evan Teran Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: properties? Date: Wed, 9 Aug 2017 22:02:15 -0700 (PDT) Lines: 112 Approved: news@gmane.org Message-ID: References: <6ed2bd55-5538-418f-8f1a-263a9958babd@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_506_1756726524.1502341335571" X-Trace: blaine.gmane.org 1502341339 16246 195.159.176.226 (10 Aug 2017 05:02:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 10 Aug 2017 05:02:19 +0000 (UTC) Cc: bop@gmb.dk To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCDNZQVEQMLRBWGRV7GAKGQEQQAK7WI@isocpp.org Thu Aug 10 07:02:14 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f198.google.com ([209.85.216.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dffbn-0003ki-R0 for gclcip-std-proposals@m.gmane.org; Thu, 10 Aug 2017 07:02:12 +0200 Original-Received: by mail-qt0-f198.google.com with SMTP id l13sf40001884qtc.15 for ; Wed, 09 Aug 2017 22:02:18 -0700 (PDT) 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=0oSuhvn/w+k/z3V9u7hGz8r6FpHEavrEAPa/u0XXa+w=; b=j4z7fV7/sQ4Oijb7sqNX9Doh/Kd5eU6IQ7LfXeQbJKuD1kucJnk6hVAQAIxSSxgLtH nO5NO7SeD84bt3fWi9uVhjLCBbeCTo+6LaX3bGpRs0gyykA6epnfv88vGynvRLKDCtni xHbNVHcoOmPvNkU4wN+s7rG1DhHoEhJe2ZxZCFgxvHbbE5x4YNKvlII5n7pRHPXA5CkK idZb1FZaQPj+273oofjP1DqWkI86uXUfk0vEQLQvy5V+/4Rstvizg3KPVZBVEav6ZIi9 Ui6gGF7Ooo35XSXsjZn7P6xCibChWPY7LopuymNDZAJ/qJ9uBFv2BdYKJIEE7SWSMQ1O aGtA== 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=0oSuhvn/w+k/z3V9u7hGz8r6FpHEavrEAPa/u0XXa+w=; b=XusyvlVvQw8lg8K317cJKE0/Wp7zBfC4aAI+9DI00jo49bcYro8Wbms1p2V5EI/v3K vgFPhjrq+SgNDDAmjU7SHmZ8PfX7VW7sTNpPcXvJjK3ddR/Z8KDQNCzgmWbh0jFoBQsM WWFUXZ8B5CuppIqksScLU5Ex2g5AJS+eNT9ve4lku9TkCjYLbjTzG89tcVqCQLRJaOH+ 3sXO6sblm3avTlyo5AjAYNhHepiTvUFZbunvUZ41yfnb0+A4DDWKLnJhvM1a4hsGngos LoeKJKYM4Ox+dDnrVImmu15eSywv/uEdR6PT9UJxwKIeElsvDAjfwBNMfeFDgW7x9nfd bcfw== 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=0oSuhvn/w+k/z3V9u7hGz8r6FpHEavrEAPa/u0XXa+w=; b=g546x3ennRTfbjb+xfTqyU3Wb+TUbD0NyaNjeu0WjaucsOo094EJCRjPm9pFaQHGmP B55FJKw1YB5jC7TYRi3a0+zS4a2L4rL4+3DjrNxXMF77G5yxTk25Y3HuNT6qpYqQ4z35 Wv74+QZ+MU1hWgJfAec1e0kBGtjN+12dCXghWL9REgijiv3uSkC75vdxHaK5WL3moPpr 7fsn0k2a9ASJFmXHC2EQ1IgH1JS2jAMLQmUSZymM35ytiw2Kc/eILN+lQz27ItblEz10 GkmSBp/yLSv3cOa4CCqSobKbXyB2Ul81sTU9E/YgmvwE6h8dceWoL93D5y0ph3n8y9T3 pARw== X-Gm-Message-State: AHYfb5gnOTY9mJ2tdlxInpqeDv0om8cdtXeA3uZ48BiOBV223KUOsPjy gZn+pTgfDyd0McF0 X-Received: by 10.200.40.4 with SMTP id 4mr6884203qtq.23.1502341337564; Wed, 09 Aug 2017 22:02:17 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.29.85 with SMTP id 82ls10624050itj.21.canary-gmail; Wed, 09 Aug 2017 22:02:16 -0700 (PDT) X-Received: by 10.31.160.13 with SMTP id j13mr62667vke.25.1502341336118; Wed, 09 Aug 2017 22:02:16 -0700 (PDT) In-Reply-To: X-Original-Sender: evan.teran@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:33775 Archived-At: ------=_Part_506_1756726524.1502341335571 Content-Type: multipart/alternative; boundary="----=_Part_507_1391265353.1502341335571" ------=_Part_507_1391265353.1502341335571 Content-Type: text/plain; charset="UTF-8" Hmm, I don't know why when i typed "properties" into the search it came up empty, maybe an unlucky network quirk :-/. Regardless, I see them now, and yes, it does seem that they have been discussed numerous times in many different ways. @Matthew, yea, I was fairly certain that the syntax was not viable, only used it for illustrative purposes. I am certain that better syntax could be developed that would be more robust. I will certainly take a look at discussing involving inline classes. That's for the pointer on that one. @Nicol, sounds interesting. If inner classes allow a library solution, that sounds great. I've toyed with some library solutions, but at the moment, it takes a bunch of macro usage to make them remotely "pretty". @Bo, Yes, Of course I could just add the () and they'll "just work". it is true that this is just syntax. But I think better syntax is sometimes a worthy goal if it makes the code better. I see what you are saying about changing the performance characteristics of "reading a member" would be viewed as an API change. I do however think it's a matter of perspective. Any function or method can become arbitrarily more complex between versions; if the way to use it remains the same, and the result is effectively the same, then I would at least call it "compatible" with the previous API. Sure, it's different, if it's more expensive but it is conceptually compatible. I'd leave it to the library writers to inform users if there is a catastrophic change in performance. As for the bitfield replacements, I understand that it's not a problem that you've encountered, but when dealing with (or emulating) hardware it can be a concern. I need a specific bit to be set, and I'd love to give it a name, so the code is nice and readable. But it's quite easy to fall into the land of compiler specific or arch specific behaviors. It would be nice if I had the ability to do this portable between compilers and compiler versions. Anyway. Bottom line is that I see that this has been discussed... a lot. And I have a lot of reading to do if I am wanting to have a change of making an informed contribution to the discussion. Thanks for humoring my post. Evan -- 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/d4dae6fc-5a58-48be-a7a3-cd2496a470a1%40isocpp.org. ------=_Part_507_1391265353.1502341335571 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hmm, I don't know why when i typed "properties&qu= ot; into the search it came up empty, maybe an unlucky network quirk :-/. R= egardless, I see them now, and yes, it does seem that they have been discus= sed numerous times in many different ways.

@Matthew, yea, I was fair= ly certain that the syntax was not viable, only used it for illustrative pu= rposes. I am certain that better syntax could be developed that would be mo= re robust. I will certainly take a look at discussing involving inline clas= ses. That's for the pointer on that one.

@Nicol, sounds interest= ing. If inner classes allow a library solution, that sounds great. I've= toyed with some library solutions, but at the moment, it takes a bunch of = macro usage to make them remotely "pretty".

@Bo, Yes, Of c= ourse I could just add the () and they'll "just work". it is = true that this is just syntax. But I think better syntax is sometimes a wor= thy goal if it makes the code better. I see what you are saying about chang= ing the performance characteristics of "reading a member" would b= e viewed as an API change. I do however think it's a matter of perspect= ive. Any function or method can become arbitrarily more complex between ver= sions; if the way to use it remains the same, and the result is effectively= the same, then I would at least call it "compatible" with the pr= evious API. Sure, it's different, if it's more expensive but it is = conceptually compatible. I'd leave it to the library writers to inform = users if there is a catastrophic change in performance.

As for the b= itfield replacements, I understand that it's not a problem that you'= ;ve encountered, but when dealing with (or emulating) hardware it can be a = concern. I need a specific bit to be set, and I'd love to give it a nam= e, so the code is nice and readable. But it's quite easy to fall into t= he land of compiler specific or arch specific behaviors. It would be nice i= f I had the ability to do this portable between compilers and compiler vers= ions.

Anyway.

Bottom line is that I see that this has been di= scussed... a lot. And I have a lot of reading to do if I am wanting to have= a change of making an informed contribution to the discussion.

Thanks for humoring my post.
Evan

--
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/d4dae6fc-5a58-48be-a7a3-cd2496a470a1= %40isocpp.org.
------=_Part_507_1391265353.1502341335571-- ------=_Part_506_1756726524.1502341335571-- .