From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: calling function but ignoring results Date: Wed, 30 Jun 2021 01:06:38 -0500 Organization: JSA Research & Innovation Message-ID: References: <69a59fdc-72bb-4202-99fc-d776530de653n@googlegroups.com> Injection-Date: Wed, 30 Jun 2021 06:06:39 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="18476"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:62303 List-Id: "Dmitry A. Kazakov" wrote in message news:sbg04v$i7i$1@gioia.aioe.org... ... > Now if you wanted to skip an integer in the file you could not do it in > the proposed way: > > @ := Get (Standard_Input); -- Ambiguous > > @ := Integer'(Get (Standard_Input)); -- Ugly Maybe you think qualification is "ugly", but it is precisely the Ada tool for this sort of problem. It wouldn't make sense to invent a new mechanism when an existing one does the job just fine (and it's hard to imagine a disambiguation mechanism that didn't include the subtype name). > I would not say that pieces like: > > declare > Ignore : constant Bar := Foo (Baz); > begin > null; > end; In Ada 202x, renaming is easier (assuming the usual case where overloading isn't involved): declare Ignore renames Foo (Baz); begin null; end; BTW, I disagree with the OP's premise. To me, this sort of thing is *exactly* what you need to do, since it makes it clear that you are ignoring the result. And that typically is hidden inside of a thicker binding, so it's pretty rare (it won't happen in well-designed Ada packages, but as Dmitry says, it will often happen in interfacing, at least with the Microsoft stuff!). ... > But excessive overloading may lead to unexpected collisions if you have > many parameters with defaults. Excessive overloading is obviously bad, so the above doesn't say much. :-) Determining when overloading is excessive is the hard part. Recent experience suggests that a lot of overloading is ultimately execessive (the need to change the name of some containers procedures demonstrates this!!) Randy.