220 10604 <20140510164133.GA7642@sara.home> article
Path: news.gmane.org!not-for-mail
From: Magnus Fromreide <magfr@lysator.liu.se>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: Forward declaring names
Date: Sat, 10 May 2014 18:41:34 +0200
Lines: 59
Approved: news@gmane.org
Message-ID: <20140510164133.GA7642@sara.home>
References: <20140509221552.GA32099@sara.home>
 <A40FA588-CE05-429B-B8B8-1A3321092B71@gmail.com>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Trace: ger.gmane.org 1399740108 17452 80.91.229.3 (10 May 2014 16:41:48 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Sat, 10 May 2014 16:41:48 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBDELLREETMBRBQFNXGNQKGQEV5OKGXQ@isocpp.org Sat May 10 18:41:41 2014
Return-path: <std-proposals+bncBDELLREETMBRBQFNXGNQKGQEV5OKGXQ@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-la0-f71.google.com ([209.85.215.71])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBDELLREETMBRBQFNXGNQKGQEV5OKGXQ@isocpp.org>)
	id 1WjALB-0002eH-Sj
	for gclcip-std-proposals@m.gmane.org; Sat, 10 May 2014 18:41:37 +0200
Original-Received: by mail-la0-f71.google.com with SMTP id mc6sf521077lab.6
        for <gclcip-std-proposals@m.gmane.org>; Sat, 10 May 2014 09:41:37 -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:subject:message-id:mail-followup-to
         :references:mime-version:in-reply-to:user-agent:x-original-sender
         :x-original-authentication-results:reply-to:precedence:mailing-list
         :list-id:list-post:list-help:list-archive:list-subscribe
         :list-unsubscribe:content-type:content-disposition;
        bh=qxftd4XQFR69YQzRiRT6WDtVlSlKhGudecJyUjtofSA=;
        b=knFQ3CQdhpEPKLBu3nBGeKKRfByMGO5BUH05In3wZq2XkFgEd+MCU/cGFvuZFTN0Yd
         WokAZ/JPIaQ9mWU+8B2yq4Uk9MDF/YOJL0ZZ3BZZoLfQsFcH/EjbIm3dj9pY+X4EMJM+
         mZXzeNFz6wuZxjAFe91cRqWUpe3yQ6RMLrXQM72+6W0ypiRmYkZf7OHtJLZLA2HROGBu
         eeS432EEVVsHxz3MwX9dTutiB0qZtA5bEz1c5CqszQfzYYupbJOWbsyIQjwZ/tHCTXlo
         OizE+hPpq4hMqZqvhBxIOLCnwauxnu/4snEzSUieZJUqMnF4oh3A1g8yZqvvHgzrDM+X
  
X-Gm-Message-State: ALoCoQmdOr6ZEZAD8qNf3GbuP/ZMkbUGLldJJaMS4LJ6FBBqoQZjL/uNn57VSYhYimRDMpz/8CVI
X-Received: by 10.152.170.130 with SMTP id am2mr189976lac.8.1399740097414;
        Sat, 10 May 2014 09:41:37 -0700 (PDT)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.152.23.41 with SMTP id j9ls78019laf.34.gmail; Sat, 10 May 2014
 09:41:36 -0700 (PDT)
X-Received: by 10.112.40.101 with SMTP id w5mr5023434lbk.19.1399740096333;
        Sat, 10 May 2014 09:41:36 -0700 (PDT)
Original-Received: from mail.lysator.liu.se (mail.lysator.liu.se. [2001:6b0:17:f0a0::3])
        by mx.google.com with ESMTPS id ds6si3328272lbc.222.2014.05.10.09.41.36
        for <std-proposals@isocpp.org>
        (version=TLSv1 cipher=RC4-SHA bits=128/128);
        Sat, 10 May 2014 09:41:36 -0700 (PDT)
Received-SPF: pass (google.com: domain of magfr@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) client-ip=2001:6b0:17:f0a0::3;
Original-Received: from mail.lysator.liu.se (localhost [127.0.0.1])
	by mail.lysator.liu.se (Postfix) with ESMTP id DAC2540008
	for <std-proposals@isocpp.org>; Sat, 10 May 2014 18:41:35 +0200 (CEST)
Original-Received: from sara.home (h-176-10-249-241.na.cust.bahnhof.se [176.10.249.241])
	(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
	(No client certificate requested)
	by mail.lysator.liu.se (Postfix) with ESMTPSA id C296D40003
	for <std-proposals@isocpp.org>; Sat, 10 May 2014 18:41:35 +0200 (CEST)
Mail-Followup-To: std-proposals@isocpp.org
In-Reply-To: <A40FA588-CE05-429B-B8B8-1A3321092B71@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Virus-Scanned: ClamAV using ClamSMTP
X-Original-Sender: magfr@lysator.liu.se
X-Original-Authentication-Results: mx.google.com;       spf=pass (google.com:
 domain of magfr@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted
 sender) smtp.mail=magfr@lysator.liu.se
Precedence: list
Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org
List-ID: <std-proposals.isocpp.org>
X-Google-Group-Id: 399137483710
List-Post: <http://groups.google.com/a/isocpp.org/group/std-proposals/post>, <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?topic=25838>, <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>
Content-Disposition: inline
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:10604
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/10604>

On Sat, May 10, 2014 at 01:41:59PM +0800, David Krauss wrote:
> 
> On 2014-05-10, at 6:15 AM, Magnus Fromreide <magfr@lysator.liu.se> wrote:
> 
> > The strong typedef should introduce a new type and place it in the same
> > namespace as class-names.
> 
> Is your intent to "bite off" a piece of the strong typedef proposal and
> implement it in anticipation of a more complete feature?

Not really - I was edging for the ability to forward declare the strong
typedef and n3741 explicitly forbids that.

> > So the proposal is something along the lines of
> > 
> > // Declare two types, say nothing of what they contain
> > 
> > strong typedef aType;
> > strong typedef aClass;
> > 
> > // Actually define the types
> > 
> > strong typedef int aType; // possibly allow ommitting strong here?
> > class aClass { };
> 
> I don't think transforming a typedef-name to a class-name should be allowed;
> you would need
> 
> strong typedef class aClass_class {
>     ...
> } aClass;

Fair enough.

> I suspect your problem may be solved with metaprogramming, namely a
> template alias mapping from a set of tag classes ("strong typedef-names")
> to a set of mapped types (which may or may not be classes) via a set of
> explicit specializations ("strong typedef declarations"). If that's too
> much, simply organizing the forward declarations might do.

I also suspect that it could be done using template metaprogramming but that
have a tendency to end up beeing more complex than the original problem.

What I wanted to solve was to make it possible to say that 'aType' refers to
a type, but it is not yet specified which type it is.

I suppose this one could go in as an extension of n3741 but then the problem
is that the proposed syntax of n3741 prevents forward declaration of typedefs.

/MF

-- 

--- 
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/.

.
