From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,2e6723b897ab47fb X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.180.24.135 with SMTP id u7mr52845wif.3.1344414479240; Wed, 08 Aug 2012 01:27:59 -0700 (PDT) Path: q11ni23542454wiw.1!nntp.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!newsfeed.utanet.at!texta.sil.at!news.nobody.at!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: "J-P. Rosen" Newsgroups: comp.lang.ada Subject: Re: Ada.Locales pseudo-string types Date: Wed, 08 Aug 2012 10:28:00 +0200 Organization: A noiseless patient Spider Message-ID: References: <78707b6e-88a3-453a-a37c-840f7a62e703@googlegroups.com> <7303f906-0f6a-4d97-ae15-36b4056ede6c@googlegroups.com> <257b4f44-b6c6-4c79-8c6e-dec947a3ce25@googlegroups.com> Mime-Version: 1.0 Injection-Date: Wed, 8 Aug 2012 08:27:59 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="cde0054f05a4d4958ef5363f6c36ea72"; logging-data="29205"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18zZZuEmU2k0ih5UtHcXB/p" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: Cancel-Lock: sha1:cVErq4wNczSHnfLPj04U5Vvk3qU= X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: 2012-08-08T10:28:00+02:00 List-Id: Le 08/08/2012 09:37, Niklas Holsti a �crit : > But we are talking about explicitly requested type conversions, not > implicit type equivalence. As I understood it, at least. Yes, or more precisely, about the special rules for array conversions, which are allowed if the types are structurally "close enough". > >>> For a value conversion, >>> the default could be to convert element by element, and the compiler >>> could then optimize this conversion based on what it can deduce >>> statically about the matching of the source and target subtypes. >> >> Could be interesting when elements themselves are arrays of discriminated >> record subtypes constrained via discriminants with array components again >> constrained etc. > > Sure, but this should not require much new intelligence in the compiler. > An array type conversion of the form A1 := A1_Type(A2); could just as > well be written as an explicit loop with explicit element-by-element > conversions, A1(I) := A1_Element_Type(A2(I)). A compiler could do this > expansion internally, giving code that is legal today and which the > compiler should already be able to compile. > That's the whole point: a possible costly loop implicitely generated by the compiler. The design choice was to /not/ hide this, i.e. allow array conversions only when no extra code was required. You are free to disagree with that design choice, of course... -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr