220 14315 article Path: news.gmane.org!not-for-mail From: Thibaut Lutz Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Omitting namespace/class scopes for scoped enums Date: Wed, 29 Oct 2014 09:45:11 -0700 (PDT) Lines: 118 Approved: news@gmane.org Message-ID: References: <122fe218-d42a-4266-9b5a-f4d70ac56119@isocpp.org> <48626aa2-a6bd-4e7f-9fd6-a32bdb58e72c@isocpp.org> <16075892.pYMiFCkgnF@tjmaciei-mobl4> <0cc21744-e9ee-433c-82bd-f3894deb9a8c@isocpp.org> <54508AA9.4040008@gmx.net> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_564_2127480749.1414601111276" X-Trace: ger.gmane.org 1414601124 18258 80.91.229.3 (29 Oct 2014 16:45:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Oct 2014 16:45:24 +0000 (UTC) Cc: mw_triad@users.sourceforge.net To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC66PHON7ACRBGFTYSRAKGQEMXRSARI@isocpp.org Wed Oct 29 17:45:18 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f69.google.com ([209.85.220.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XjWMz-0002Yq-Ny for gclcip-std-proposals@m.gmane.org; Wed, 29 Oct 2014 17:45:13 +0100 Original-Received: by mail-pa0-f69.google.com with SMTP id eu11sf18391403pac.0 for ; Wed, 29 Oct 2014 09:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; 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:content-type; bh=Ri7h0v9ZK7okrm2WeL/ZS1uolgOKDBgSXdgzY7qTEFE=; b=YfwQKOpWIa+Ks3kECHIjPRJbD47BLE1MaJQjzrdg70FYH/ilfXMrKLF86lg+Af2bn8 p6bfSXNfA5q7fob01yPMKlCNwnrVFUm5WpT8N/fLF3onwjLs+UdPbeulZmDox+FWAadA LFxh9ZL+ugIk3KwkbaEwx2E3IIzu5TASz0100xDfJ6NL8W743AF10+dg9pJOu+3Aagy/ 12+i5AtCl5NECSx+udkFliRQrtuwfpYV5ecyShkp6y3YDZdqju5M+ncxzOkXQlpSpKC/ faIXN8Qqtf+w2EQ55iyCPZEP7AenIZfXWNgvx+f+dAHKb4zv0xkXdieXKsSN2v2A6Dmu f8iA== 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: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:content-type; bh=Ri7h0v9ZK7okrm2WeL/ZS1uolgOKDBgSXdgzY7qTEFE=; b=WLhLuQxfwfnH5UHpqaPvUuuo+/GYucenxWMFfPBYvtvwvJYiczpRWe9v3CRX+v/c2U yKczLaSdiEKIrfpI/eecMjb3cjsuPjfw3T9zilPCPN4ekYsxHLPG7tPJg2p9cwDjqNUd jLWRtkU9pWXNEuXGzcvwzdHsB0S1jBHQxt+U5ixRF58km2xu4oiYDJ9UwO4EwHdX33AX tCspOH2rAU9BaPOlTNWFp2GCwpNYs+6WwGq25Opp6mfxBYa68U9ZCw/xoVaYeDdaJw4U bGUCTyWk3cyxoX4r26fHZlgo8CcnCPCuoMnEL5/0Ti0AcPIIfXuoCSQ2l8mabLvqGpsu 5hrg== X-Gm-Message-State: ALoCoQn4jcObS+pyJla6RMbW3imODM6nU7vKnJUjSEDhy12pLXMtTg0PH9gJhONnZt880KT+lB28 X-Received: by 10.70.63.106 with SMTP id f10mr8034619pds.1.1414601112591; Wed, 29 Oct 2014 09:45:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.97.34 with SMTP id l31ls872828qge.82.gmail; Wed, 29 Oct 2014 09:45:11 -0700 (PDT) X-Received: by 10.140.82.75 with SMTP id g69mr50953qgd.9.1414601111838; Wed, 29 Oct 2014 09:45:11 -0700 (PDT) In-Reply-To: X-Original-Sender: thibaut.lutz@googlemail.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:14315 Archived-At: ------=_Part_564_2127480749.1414601111276 Content-Type: text/plain; charset=UTF-8 > > The first is only useful at a point of use. > They can both be used within a single scope, but one would injects the enumerators in the namespace and the other still nicely encloses the enum in a shorter named scope. > IMHO this is a *defect* in strongly typed enums; it *does not* always > make sense to restrict the enum values to an additional scope > (especially when they are already in some other scope). Personally, I > often do not use strongly typed enums for exactly this reason; because > the cost to the user of having to needlessly repeat an extra namespace > qualifier is considered unacceptable. > But isn't it the whole point of it though, that the scope must be explicit at all times? It would be the same argument as saying one should use global variables in a namespace instead of static class members, just because their names can be injected at the point of use for convenience. Qt is a good case in point. Right now you can write e.g. Qt::AlignLeft, > Qt::white, Qt::TopLeftCorner, etc. All of these are different enums, but > they can be used without repeating the (often long) enum name. This is probably because you have grown accustomed to the interface as it it, and because the interface was designed before this feature. Note that the enums, and even the enumerators, have long and clunky names *because* they didn't have scoped enums and they had to avoid name clashes somehow. I personally think that having well named strongly typed enums which can share otherwise conflicting enumerator names makes for much better code. To take your Qt example, I think Qt::*Align*::*Left*, Qt::*Anchor*::*Left* and Qt::*Elide*::*Left* would have made the code and the documentation a lot nicer. It is a shame older interfaces cannot introduce this feature without breaking code, yes, but I don't think it would make the interfaces awkward. A similar discussion must have taken place a long time ago about pulling old-style class scoped enums or static members out of the class scope using a "using class ..." construct or similar, maybe it would be a good place to find arguments for and against. I must say it still sounds like a bad idea to me. -- --- 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/. ------=_Part_564_2127480749.1414601111276 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The first is = only useful at a point of use.

They ca= n both be used within a single scope, but one would injects the enumerators= in the namespace and the other still nicely encloses the enum in a shorter= named scope.
 
IMHO this is a *defect* in strongly typed enums; it *does not* always
make sense to restrict the enum values to an additional scope
(especially when they are already in some other scope). Personally, I
often do not use strongly typed enums for exactly this reason; because
the cost to the user of having to needlessly repeat an extra namespace
qualifier is considered unacceptable.

But isn't it the whole point of it though, that the scope must be explic= it at all times? It would be the same argument as saying one should use glo= bal variables in a namespace instead of static class members, just because = their names can be injected at the point of use for convenience.
=
Qt is a good case in= point. Right now you can write e.g. Qt::AlignLeft,
Qt::white, Qt::TopLeftCorner, etc. All of these are different enums, bu= t
they can be used without repeating the (often long) enum name.

This is probably because you have grown accus= tomed to the interface as it it, and because the interface was designed bef= ore this feature. Note that the enums, and even the enumerators, have long = and clunky names because they didn't have scoped enums and they had = to avoid name clashes somehow. 
I personally think that havi= ng well named strongly typed enums which can share otherwise conflicting en= umerator names makes for much better code. To take your Qt example, I think= Qt::Align::Left, Qt::Anchor::Left and Qt::E= lide::Left would have made the code and the documentation a lot = nicer. It is a shame older interfaces cannot introduce this feature without= breaking code, yes, but I don't think it would make the interfaces awkward= ..

A similar discussion must have taken place a lon= g time ago about pulling old-style class scoped enums or static members out= of the class scope using a "using class ..." construct or similar, maybe i= t would be a good place to find arguments for and against. I must say it st= ill sounds like a bad idea to me.

--

---
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_564_2127480749.1414601111276-- .