Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #69950
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: Substitution failure can be an error |
| Date | 2019-11-21 12:34 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <qr5sol$hat$1@dont-email.me> (permalink) |
| References | (5 earlier) <X0ZAF.192255$vV6.46521@fx17.am4> <qr2suu$pf0$1@dont-email.me> <64d70389-c0ea-45fc-a2a3-4c39f11c2fc7@googlegroups.com> <zSbBF.110778$fL4.75484@fx41.iad> <0413d801-0234-451f-ba04-e63a35619e5d@googlegroups.com> |
On 20/11/2019 17:34, Öö Tiib wrote:
> On Wednesday, 20 November 2019 16:14:02 UTC+2, Scott Lurndal wrote:
>> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> writes:
>>> On Wednesday, 20 November 2019 10:19:56 UTC+2, David Brown wrote:
>>>>
>>>> But I really do not see any benefit of writing:
>>>>
>>>> auto foo(int a) -> double
>>>> {
>>>> return a * 1.2345;
>>>> }
>>>
>>> No way out of it. It is in language so we all must be capable
>>> to read it (even if we dislike it and refuse to write it).
>>>
>>> What I think is that it is half-solution of moving C++ from type
>>> being smeared around name towards type last. Lot of other
>>> languages, (including number of C-like languages) have
>>> type last:
>>>
>>> function foo(a: integer): double;
>>>
>>> Designers of those languages considered it more clear
>>> and readable.
>>
>> Did they? Or were they simply following some earlier example?
>
> Certainly there were plenty of examples of every kind.
>
> I meant designers of newer C-like languages Go, Rust and
> Swift.
>
> They switched to type being last in declarations while
> all previous attempts of "better" C, (C++, Objective-C,
> Java, D and C#) had type first or around name like in C?
>
Fair enough for the facts of these languages - they have the type coming
last. (I am taking your word for that - I don't know the details of
them.) What is your evidence for the reason for this choice? You say
the "designers of those languages considered it more clear and readable"
- is that just your guess, or have they published rationales or other
information explaining their reasoning? (I hope it is the later, as
those could be very interesting reads.)
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Substitution failure can be an error "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-18 18:49 +0100
Re: Substitution failure can be an error Vir Campestris <vir.campestris@invalid.invalid> - 2019-11-18 21:54 +0000
Re: Substitution failure can be an error Sam <sam@email-scan.com> - 2019-11-18 18:12 -0500
Re: Substitution failure can be an error Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-19 03:53 +0000
Re: Substitution failure can be an error "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-19 12:48 +0100
Re: Substitution failure can be an error Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-19 19:48 +0000
Re: Substitution failure can be an error "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-19 21:31 +0100
Re: Substitution failure can be an error Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-19 21:20 +0000
Re: Substitution failure can be an error "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-19 22:51 +0100
Re: Substitution failure can be an error Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-19 21:58 +0000
Re: Substitution failure can be an error David Brown <david.brown@hesbynett.no> - 2019-11-20 09:19 +0100
Re: Substitution failure can be an error Öö Tiib <ootiib@hot.ee> - 2019-11-20 02:16 -0800
Re: Substitution failure can be an error scott@slp53.sl.home (Scott Lurndal) - 2019-11-20 14:13 +0000
Re: Substitution failure can be an error Öö Tiib <ootiib@hot.ee> - 2019-11-20 08:34 -0800
Re: Substitution failure can be an error David Brown <david.brown@hesbynett.no> - 2019-11-21 12:34 +0100
Re: Substitution failure can be an error Öö Tiib <ootiib@hot.ee> - 2019-11-21 05:29 -0800
Re: Substitution failure can be an error David Brown <david.brown@hesbynett.no> - 2019-11-21 15:58 +0100
Re: Substitution failure can be an error Christian Gollwitzer <auriocus@gmx.de> - 2019-11-20 11:12 +0100
Re: Substitution failure can be an error Öö Tiib <ootiib@hot.ee> - 2019-11-20 04:25 -0800
Re: Substitution failure can be an error Öö Tiib <ootiib@hot.ee> - 2019-11-20 06:05 -0800
Almost Always Auto? (was Re: Substitution failure can be an error) Vir Campestris <vir.campestris@invalid.invalid> - 2019-11-22 21:46 +0000
Re: Almost Always Auto? (was Re: Substitution failure can be an error) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-23 09:29 +0000
Re: Almost Always Auto? (was Re: Substitution failure can be an boltar@nowhere.co.uk - 2019-11-23 17:23 +0000
Re: Almost Always Auto? (was Re: Substitution failure can be an error) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 12:46 -0800
Re: Almost Always Auto? (was Re: Substitution failure can be an error) "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-24 00:26 +0100
Re: Almost Always Auto? (was Re: Substitution failure can be an error) "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-24 00:28 +0100
Re: Almost Always Auto? (was Re: Substitution failure can be an error) "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-24 00:45 +0100
Re: Almost Always Auto? (was Re: Substitution failure can be an boltar@nowhere.co.uk - 2019-11-24 10:47 +0000
Re: Almost Always Auto? (was Re: Substitution failure can be an Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-24 13:37 +0000
Re: Almost Always Auto? (was Re: Substitution failure can be an boltar@nowhere.co.uk - 2019-11-25 11:08 +0000
Re: Substitution failure can be an error Manfred <noname@add.invalid> - 2019-11-20 18:46 +0100
Re: Substitution failure can be an error "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-21 06:02 +0100
Re: Substitution failure can be an error Manfred <noname@add.invalid> - 2019-11-21 15:50 +0100
csiph-web