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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: buffer2.nntp.dca1.giganews.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!1.eu.feeder.erje.net!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Incompatible types for array conversion Date: Mon, 27 Jul 2015 18:12:13 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1438038735 7245 24.196.82.226 (27 Jul 2015 23:12:15 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 27 Jul 2015 23:12:15 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: number.nntp.giganews.com comp.lang.ada:194367 Date: 2015-07-27T18:12:13-05:00 List-Id: "Simon Wright" wrote in message news:ly1tg0jrtm.fsf@pushface.org... > Niklas Holsti writes: > >> On 15-07-22 10:13 , Simon Wright wrote: >>> Niklas Holsti writes: >>> >>>> The conversion is rejected because of the conversion condition in RM >>>> 4.6 (24.5/2): "The component subtypes shall statically match". The >>>> component (sub)types are Real and Length, which are different types, >>>> although Length is derived from Real. If you change the declaration >>>> of Length to be >>>> >>>> subtype Length is Real; >>>> >>>> the conversion becomes legal. >>> >>> I tried >>> >>> generic >>> dim: positive; >>> type Real is digits <>; >>> package Vectors is >>> type Vector is array (1..dim) of Real'Base; >>> >>> but it still failed. (GPL 2015, FSF 5.1.0) >> >> Did you expect it to work? Real'Base gets rid of any constraints on >> Real, but AIUI does not get rid of the type derivation; if "type >> Length is new Real", Length'Base is not the same as Real'Base -- the >> "new" makes them different. > > Well, who knows what 'statically match' means! (outside the ARG, > anyway). I thought it was worth a try. It's clearly ;-) explained in ARM 4.9.1. Short summary: it's the same type with the same constraint. We use statically match simply so that things that are "obviously" the same are treated as such: subtype S1 is Int range 1 .. 10; subtype S2 is Int range 1 .. 10; S1 and S2 statically match (as one would hope). But if someone declared separate types in Ada (as in "new"), they're really different, and then they can never statically match (because they don't match in any way). Some other parts of type conversions use "convertible", which would allow such conversions. I think the rules for array components are too strict, but simply using "convertible" doesn't work for various obscure reasons, and coming up with a concept just for this case isn't worth it. (We looked at this as one of the solutions for AI12-0037-1, but in the end we just changed the declarations of the types instead.) Randy.