220 27203 article Path: news.gmane.org!not-for-mail From: "D. B." Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Generalized "using" member aliases. Date: Fri, 22 Jul 2016 08:40:34 +0100 Lines: 85 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11468e08caf2890538348ce0 X-Trace: ger.gmane.org 1469173253 10456 80.91.229.3 (22 Jul 2016 07:40:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Jul 2016 07:40:53 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCWNZ4ECS4GBB5E3Y66AKGQEKMVOQZQ@isocpp.org Fri Jul 22 09:40:38 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f70.google.com ([209.85.215.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bQV4Y-0007WP-Ce for gclcip-std-proposals@m.gmane.org; Fri, 22 Jul 2016 09:40:38 +0200 Original-Received: by mail-lf0-f70.google.com with SMTP id p41sf66709989lfi.0 for ; Fri, 22 Jul 2016 00:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :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=NTGCqrwTMBnWVUf4jR4NN4TE7ttlKcW7S2hsfRax1F8=; b=01xBhXp7C7SHM86BKl/lBDZzRt35AmG5J5gFAGZD0CR2WKYL02t/3ySywpuKKB7/aT qfcWLy+R9IQawrXgGA36rHctyl/h2pp0y1x5d+QfxOEjg9+YLkF+ViQiaWydftHYlATh jniwrP2mJEhQPXL9J35izqTDv3jbZ2agToJSodQI6bR+StAe7Utzzcs2JbzOyZkAUiPn a2JpngAPYlfAHfppz+/+R+AInWeUCFQxHEd1AbHjQeFFO9y/ajoc2Y1QW1fJ/MWjw99b c+gFIshIiXMjV2274wUU7XDOffcCw0BkMDGVqqREutLtgfltFtafKGraK9fH6PiB1erN JlQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to: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=NTGCqrwTMBnWVUf4jR4NN4TE7ttlKcW7S2hsfRax1F8=; b=U6zc+hLBw5S65Sd1rqwmf82LfS4kecyscvAOqenRUthi7GOLk5veU21B9p7uDhLkgM 5OB2xdiAcxU8/HN+SLlzTZiqVCq6iAcuwtjmvtedF9rXi8IhjwwwY8qtAU46BjxmRqP4 Y/RMasFIRbzUEdhEKF8RCCSA7lNfT7DJJkrfzmWNJakIpSIScD4G+SjhomQkWJMRJCSL uWS2xfhAzlB0slq47RvYkv7Sy4cFIPppAeP3DBXEW4QprcB7oSorYwpVGZjvdr0ZlIt9 kyZZL9lJ9f2xGT7CcG3mNgpwSZCtZIIFV0brCOhZ7v6EIbqHJk08pECWe4BAkvlIwdLd 70FA== X-Gm-Message-State: ALyK8tLayBzNTJgDJ0VuIp8hMukemVa6YQXCO3En50uy50tPF5MZIxzWEsGv/Vo2MP8h2A== X-Received: by 10.28.167.144 with SMTP id q138mr2362879wme.3.1469173237581; Fri, 22 Jul 2016 00:40:37 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.206.5 with SMTP id e5ls651364wmg.19.gmail; Fri, 22 Jul 2016 00:40:36 -0700 (PDT) X-Received: by 10.28.216.75 with SMTP id p72mr25009439wmg.67.1469173235597; Fri, 22 Jul 2016 00:40:35 -0700 (PDT) Original-Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com. [2a00:1450:400c:c09::241]) by mx.google.com with ESMTPS id 198si8685635wmi.81.2016.07.22.00.40.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jul 2016 00:40:35 -0700 (PDT) Received-SPF: pass (google.com: domain of db0451@gmail.com designates 2a00:1450:400c:c09::241 as permitted sender) client-ip=2a00:1450:400c:c09::241; Original-Received: by mail-wm0-x241.google.com with SMTP id o80so4906731wme.0 for ; Fri, 22 Jul 2016 00:40:35 -0700 (PDT) X-Received: by 10.28.94.18 with SMTP id s18mr3416538wmb.44.1469173235117; Fri, 22 Jul 2016 00:40:35 -0700 (PDT) Original-Received: by 10.28.90.65 with HTTP; Fri, 22 Jul 2016 00:40:34 -0700 (PDT) In-Reply-To: X-Original-Sender: db0451@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of db0451@gmail.com designates 2a00:1450:400c:c09::241 as permitted sender) smtp.mailfrom=db0451@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:27203 Archived-At: --001a11468e08caf2890538348ce0 Content-Type: text/plain; charset=UTF-8 How would one disambiguate between 'aliased members' and typenames in the outer scope, which might well overlap? Would the former now have to take precedence? What would the syntax be for resolving ambiguous aliases? I dunno, it seems like a lot of work for little benefit. Or for negative benefit in some cases: "ExistingName could also specify a function, e.g., "ExistingName()", in which case NewName becomes a property-like element." - But then we have horribly ambiguous syntax for whether something is a member variable or method, requiring us to constantly consult the class to unearth byzantine using declarations, which don't produce "property-like elements" anyway if the function signature doesn't return a modifiable reference. "Member aliases could also be used to shorten inconveniently long names" - thereby producing 2 names for the same object, cluttering the namespace and introducing ambiguity, merely to remove the responsibility of users not to choose stupidly long names? "This brings tuples one step closer to being a struct replacement" - sounds like ominous portent to me. structs aren't tuples, and tuples aren't structs. Neither should replace the other. Do we really need to introduce a bunch of problems such as the above just to make interface design slightly easier for the lazy ....I dunno, just playing devil's advocate. I've never felt a need for this and am not convinced that the cited rationales are good things, quite the opposite in most cases. -- 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/CACGiwhEwWaOWU9maQCXAsPMqDgeOyxMQBdVjXixfCYO_vBri9g%40mail.gmail.com. --001a11468e08caf2890538348ce0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How would one disambiguate between 'aliased membe= rs' and typenames in the outer scope, which might well overlap? Would t= he former now have to take precedence? What would the syntax be for resolvi= ng ambiguous aliases? I dunno, it seems like a lot of work for little benef= it.

Or for negative benefit in some cases:

"ExistingName= could also specify a function, e.g., "ExistingName()", in which = case NewName becomes a property-like element."
- But then we have h= orribly ambiguous syntax for whether something is a member variable or meth= od, requiring us to constantly consult the class to unearth byzantine using= declarations, which don't produce "property-like elements" a= nyway if the function signature doesn't return a modifiable reference.<= br>
"Member aliases could also be used to shorten inconveniently lo= ng names"
- thereby producing 2 names for the same object, clutteri= ng the namespace and introducing ambiguity, merely to remove the responsibi= lity of users not to choose stupidly long names?

"This brings t= uples one step closer to being a struct replacement"
- s= ounds like ominous portent to me. structs aren't tuples, and tuples are= n't structs. Neither should replace the other. Do we really need to int= roduce a bunch of problems such as the above just to make interface design = slightly easier for the lazy

...I dunno, just = playing devil's advocate. I've never felt a need for this and am no= t convinced that the cited rationales are good things, quite the opposite i= n most cases.

--
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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEwWaOWU9ma= QCXAsPMqDgeOyxMQBdVjXixfCYO_vBri9g%40mail.gmail.com.
--001a11468e08caf2890538348ce0-- .