220 14295 <0cc21744-e9ee-433c-82bd-f3894deb9a8c@isocpp.org> article Path: news.gmane.org!not-for-mail From: corentin.schreiber@cea.fr Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Omitting namespace/class scopes for scoped enums Date: Tue, 28 Oct 2014 15:02:40 -0700 (PDT) Lines: 169 Approved: news@gmane.org Message-ID: <0cc21744-e9ee-433c-82bd-f3894deb9a8c@isocpp.org> References: <122fe218-d42a-4266-9b5a-f4d70ac56119@isocpp.org> <48626aa2-a6bd-4e7f-9fd6-a32bdb58e72c@isocpp.org> <16075892.pYMiFCkgnF@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5962_550472898.1414533761000" X-Trace: ger.gmane.org 1414533772 12227 80.91.229.3 (28 Oct 2014 22:02:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Oct 2014 22:02:52 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCX4RQEPQAMBBANFYCRAKGQE62Q4STQ@isocpp.org Tue Oct 28 23:02:45 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XjEqh-0003S9-CX for gclcip-std-proposals@m.gmane.org; Tue, 28 Oct 2014 23:02:43 +0100 Original-Received: by mail-ie0-f199.google.com with SMTP id x19sf6562592ier.2 for ; Tue, 28 Oct 2014 15:02:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to: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:content-type; bh=Kl8OGn6wjG9YLrB5NerpiUJrGq2pMmgr/K2b20WrNQI=; b=HJV0Y+OFbYi9qvyj0VtBkMy+RerJolRUNjQoBLV0WjJnNYS0M8CWHf26qPFWQU9t/R prHLU/pkHwLl6XpMnSB0Lzj4PVc7JC5xMbZGo+Kf+uIB2ZwZ9K7mS1nCu0SIaV6a2v/S gC9sD4L0KnQ2Kspo1y7NAA+wPNO3tEzCy10sHD6KtNuY+WpHTqsjufxSJW/uDwWQaM5J npCjAzyJc+xAG+TmzXEBshjfCCSZlO4eaMrknZxO0I2sJeZKJTplIolkJB2Zoq39YF6S AG3l9dxbe0myaFd5EtVGYHBUU7Pw7sv1rxPhYUBzWOSqkbJqm+4c6HwjP2A7ChkOTa8r YKvQ== X-Gm-Message-State: ALoCoQl26Iv2bJ5ofNBzXE6BCDrEjnc3dWto/rAbgPoZp0LYroLW8+0epHRLB58dyrDmaBHk59wU X-Received: by 10.50.164.164 with SMTP id yr4mr22352950igb.3.1414533762454; Tue, 28 Oct 2014 15:02:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.42.56 with SMTP id b53ls443630qga.89.gmail; Tue, 28 Oct 2014 15:02:41 -0700 (PDT) X-Received: by 10.140.34.76 with SMTP id k70mr916qgk.40.1414533761561; Tue, 28 Oct 2014 15:02:41 -0700 (PDT) In-Reply-To: X-Original-Sender: corentin.schreiber@cea.fr 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:14295 Archived-At: ------=_Part_5962_550472898.1414533761000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le mardi 28 octobre 2014 21:39:42 UTC+1, Myriachan a =C3=A9crit : > > On Tuesday, October 28, 2014 12:34:12 PM UTC-7, Thiago Macieira wrote: >> >> On Tuesday 28 October 2014 12:26:23 corentin....@cea.fr wrote:=20 >> > Here is one way to implement the lookup. When initializing (or=20 >> assigning) a=20 >> > variable of enumeration type, first look for a candidate in the local= =20 >> scope=20 >> > (so as to preserve backward compatibility), then if none is found, try= =20 >> > within the name space of the object (the switch argument, the=20 >> initialized=20 >> > variable, and the variable that is assigned to, respectively).=20 >> >> That means looking up the target variable type, across the=20 >> initialisation.=20 >> That's a major language change.=20 >> >> > I previously wanted to propose a "using namespace" extension, where you= =20 > could specify a class name or enum name rather than just namespaces, but= =20 > this thread looks like a similar topic, so I'll mention what I was going = to=20 > propose. > For the record: https://groups.google.com/a/isocpp.org/d/topic/std-proposals/-3Q3C5FPuPE/di= scussion :) As for being a major language change Thiago, I do not understand why you=20 say so (nor do I know the consequences it implies). Isn't this similar to= =20 something we already have in the language: ADL? I'm no norm or compiler writer, so maybe it is indeed major in the way that= =20 it violates root concepts of C++, but I would say that from a user point of= =20 view this does not seem major at all. Philosophically, this is the same as= =20 writing: struct A { A(int) {} }; A a =3D 2; .... in the sense that '2' is understood in the context of initializing 'a'.= =20 Do not get me wrong: I do know that, technically speaking, whatever is on= =20 the right hand side of the equal sign is currently syntactically valid on= =20 its own, and forwarded as is to the constructor of A. For the compiler, the= =20 '2' here has nothing special, it is always the literal integer of value 2,= =20 no matter what is present on the left hand side of the equal sign. But my= =20 point is that, for the person reading the code, this is not true. To=20 actually understand this '2', the user will look at the type of 'a'.=20 Therefore I'm quite sure that interpreting an identifier on the rhs=20 depending on the type of the lhs will appear natural to most people. But=20 maybe that is not what you meant. --=20 ---=20 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 e= mail 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-proposa= ls/. ------=_Part_5962_550472898.1414533761000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le mardi 28 octobre 2014 21:39:42 UTC+1, Myriachan a =C3= =A9crit :
On Tuesday, October 28, 2014 12:34:12 PM UTC-7, Thiago Macieira wrote:On Tuesday 28 October 2014 12:26:23 = corentin....@cea.fr wrote:
> Here is one way to implement the lookup. When initializing (or ass= igning) a=20
> variable of enumeration type, first look for a candidate in the lo= cal scope
> (so as to preserve backward compatibility), then if none is found,= try
> within the name space of the object (the switch argument, the init= ialized
> variable, and the variable that is assigned to, respectively).

That means looking up the target variable type, across the initialisati= on.=20
That's a major language change.


I previously wanted to propose a "using namespace= " extension, where you could specify a class name or enum name rather than = just namespaces, but this thread looks like a similar topic, so I'll mentio= n what I was going to propose.

For the= record:
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/-3= Q3C5FPuPE/discussion
:)

As for being a major language change Thia= go, I do not understand why you say so (nor do I know the consequences it i= mplies). Isn't this similar to something we already have in the language: A= DL?

I'm no norm or compiler writer, so maybe it is indeed major in t= he way that it violates root concepts of C++, but I would say that from a u= ser point of view this does not seem major at all. Philosophically, this is= the same as writing:
=
struct A {
&nb= sp;   A(int) {}
};

A a =3D 2;=
... in the sense that '2' is understood in the c= ontext of initializing 'a'. Do not get me wrong: I do know that, technicall= y speaking, whatever is on the right hand side of the equal sign is current= ly syntactically valid on its own, and forwarded as is to the constructor o= f A. For the compiler, the '2' here has nothing special, it is always the l= iteral integer of value 2, no matter what is present on the left hand side = of the equal sign. But my point is that, for the person reading the code, t= his is not true. To actually understand this '2', the user will look at the= type of 'a'. Therefore I'm quite sure that interpreting an identifier on t= he rhs depending on the type of the lhs will appear natural to most people.= But maybe that is not what you meant.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_5962_550472898.1414533761000-- .