220 15189 <1c90bd4e-a251-460b-82c2-be5cea7ba820@isocpp.org> article Path: news.gmane.org!not-for-mail From: sasho648 Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Inline variables - superior of templates and constexpr. Date: Sun, 21 Dec 2014 07:34:16 -0800 (PST) Lines: 210 Approved: news@gmane.org Message-ID: <1c90bd4e-a251-460b-82c2-be5cea7ba820@isocpp.org> References: <84da1bdc-3356-4c40-a29a-bdd4c0b058b4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_217_1046862826.1419176056641" X-Trace: ger.gmane.org 1419176069 5356 80.91.229.3 (21 Dec 2014 15:34:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Dec 2014 15:34:29 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDBNZXHN2QPRB6OQ3OSAKGQE3K5NGDY@isocpp.org Sun Dec 21 16:34:22 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f199.google.com ([209.85.214.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y2iWR-0005oK-1U for gclcip-std-proposals@m.gmane.org; Sun, 21 Dec 2014 16:34:19 +0100 Original-Received: by mail-ob0-f199.google.com with SMTP id wp4sf119724749obc.2 for ; Sun, 21 Dec 2014 07:34:17 -0800 (PST) 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:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=fwKYZFVeFOyf/KTsTJi6vUeGkuaOz8JruAGHgB8RJDQ=; b=ZVs/kMRWUr6LmQ+OjnmJSGPfI+1sspxy/ODmB/XEw464m6CspSOD3E1b6nLnsQPxPW TO9AtN6gq5aT/b0aT9SNqREBwo1ellYdZBPshyo6o/UDVowT1oQJC3P976gyW/t+jGFm onn0NKPbiyDYTClmi28lxOuoXBgSlWDwK8WzZ+kbnOohAnIdaCnfrzn0l1XGfRKIuh47 Zx9GDa3i3dmPCHAYYVgE1BP/3fvrBUskNdlev60jwysLIi1i6pa13nbXnWSOd94RNRE4 pIja1XLW/GEC1FAHL5z1U3Fcu9tZuW0sGvhQcf1jx+Evy7wIIZFwiE8kQQJ3ud5rzdHo E3ow== X-Gm-Message-State: ALoCoQkE4AaulnwxbUhLxNwoUWEAMn4MPqArArYSW2L2lICHKEpJLHavqC6yW8uJoo6xCyxJP/qd X-Received: by 10.42.199.135 with SMTP id es7mr14763458icb.25.1419176057678; Sun, 21 Dec 2014 07:34:17 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.105.75 with SMTP id b69ls3307243qgf.80.gmail; Sun, 21 Dec 2014 07:34:17 -0800 (PST) X-Received: by 10.140.18.173 with SMTP id 42mr146qgf.9.1419176057048; Sun, 21 Dec 2014 07:34:17 -0800 (PST) In-Reply-To: <84da1bdc-3356-4c40-a29a-bdd4c0b058b4@isocpp.org> X-Original-Sender: sasho648@mail.bg 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:15189 Archived-At: ------=_Part_217_1046862826.1419176056641 Content-Type: multipart/alternative; boundary="----=_Part_218_289996711.1419176056641" ------=_Part_218_289996711.1419176056641 Content-Type: text/plain; charset=UTF-8 > > The above is equivalent to: > template > auto FuncAdd(X a, Y b) > { > return a + b; > } > But there's no way to enforce that the types of a and b be the same. With > explicit templates, there is. Wrong - there is a way that you can ensure that both of the parameters are from the same type, deduced from the first argument, by using 'decltype' and this actually compiles just fine in 'gcc 5.0': auto FuncAdd(auto a, decltype(a) b) ; Life example . Please explain why we need this syntax. What does it solve that the > traditional way of defining templates doesn't? And would "inline class" > apply > to class templates too? How? If not, do you think it would be bad to have > different syntaxes for classes and for functions? It's not required but it for me it's naturally to be added as there is much similarity with 'constexpr' parameters and templates as they both are evaluated at compile-time. But if you want a reason - I personally think it's more easy to write 'inline' parameters, instead of templates. But for now let's abstract from it - I was just replaying 'Douglas Boffey' post. Let's continue with the concept of 'inline' or 'constexpr' parameters. Why not? Maybe that's exactly what you want. I also see no difference > between > the above and: > void Func(int a, int b, int c); > void Func(inline int a, int b, int c); > void Func(int a, inline int b, int c); > void Func(int a, int b, inline int c); > void Func(inline int a, inline int b, int c); > void Func(inline int a, int b, inline int c); > void Func(int a, inline int b, inline int c); > void Func(inline int a, inline int b, inline int c); > If you need all 8 combinations, then you need to write them out anyway > regardless of the syntax. However, with the solution based on "if", you > can > write it all in a single function and merge the common code-paths without > having to call another function. Why don't we stop using types and detect them in 'if' statements? That's the 'C++' language - it's a type-one. Why can you do it with a keyword A but not keyword B? I don't have nothing against to be 'constexpr' too, after it is introduced in the language already and no going-back is possible. So as 'constexpr' functions could return only 'constexpr' values - we could thought them as an function declared with return value of type 'constexpr', if we replace 'inline' with 'constexpr'. And in the case we could declare 'constexpr' parameters. That depends on the definition of compile-time error. All compile-time > errors > should be reported. The discussion was whether the code was a compile-time > error in the first place or not. > I also prefer my code to be deterministic. > func(9); // will report an error > int x = 9; > func(x); // may report an error? > func(atoi(some_string)); // never reports an error? > Either the code is valid or it isn't. Anything that doesn't affect the > validity > of the code should not be an error. It may be a warning. I believe code which is sure 'UB' or instance functions with parameters not supported by them is exactly invalid code. -- --- 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_218_289996711.1419176056641 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The above is equivalent to:&n= bsp;
template <typename X, typename Y> 
auto FuncAdd(X a, = Y b) 
{ 
        re= turn a + b; 
} 
But there's no way to enforce that the type= s of a and b be the same. With 
explicit templates, there is. =

Wrong - there is a way that you can ensure= that both of the parameters are from the same type, deduced from the first= argument, by using 'decltype' and this actually compiles just fine in 'gcc= 5.0':

=
auto FuncAdd(auto a, = decltype(a) b) ;

Life example.
Please explain why we need this s= yntax. What does it solve that the 
traditional way of defining tem= plates doesn't? And would "inline class" apply 
to class templates = too? How? If not, do you think it would be bad to have 
different s= yntaxes for classes and for functions? 

It'= s not required but it for me it's naturally to be added as there is much si= milarity with 'constexpr' parameters and templates as they both are evaluat= ed at compile-time. But if you want a reason - I personally think it's more= easy to write 'inline' parameters, instead of templates. But for now let's= abstract from it - I was just replaying 'Douglas Boffey' post. Let's continue with the concept of 'inline' or 'constexpr= ' parameters.

Why not? M= aybe that's exactly what you want. I also see no difference between the above and: 
void Func(int a, int b, int c); 
void Fun= c(inline int a, int b, int c); 
void Func(int a, inline int b, int = c); 
void Func(int a, int b, inline int c); 
void Func(inli= ne int a, inline int b, int c); 
void Func(inline int a, int b, inl= ine int c); 
void Func(int a, inline int b, inline int c); void Func(inline int a, inline int b, inline int c); 
If you need = all 8 combinations, then you need to write them out anyway 
regardl= ess of the syntax. However, with the solution based on "if", you can <= br>write it all in a single function and merge the common code-paths withou= t 
having to call another function. 

Why don't we stop using types and detect them in 'if' statements? Th= at's the 'C++' language - it's a type-one.

Why can you do it with a keyword A but not keyword B? = ;

I don't have nothing against to be 'const= expr' too, after it is introduced in the language already and no going-back= is possible. 

So as 'constexpr' functions could return only 'c= onstexpr' values - we could thought them as an function declared with retur= n value of type 'constexpr', if we replace 'inline' with 'constexpr'. And i= n the case we could declare 'constexpr' parameters.

That depends on the definition of compile-time er= ror. All compile-time errors 
should be reported. The discussion wa= s whether the code was a compile-time 
error in the first place or = not. 
I also prefer my code to be deterministic. 
 &nb= sp;      func(9);    &nbs= p;           //= will report an error 
       &n= bsp;int x =3D 9; 
        f= unc(x);           &n= bsp;    // may report an error? 
 &nb= sp;      func(atoi(some_string)); &= nbsp;      // never reports an error? Either the code is valid or it isn't. Anything that doesn't affect the va= lidity 
of the code should not be an error. It may be a warning.&nb= sp;

I believe code which is sure 'UB' or in= stance functions with parameters not supported by them is exactly invalid c= ode. 

--

---
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_218_289996711.1419176056641-- ------=_Part_217_1046862826.1419176056641-- .