Groups | Search | Server Info | Login | Register
Groups > comp.os.vms > #378208
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Newsgroups | comp.os.vms |
| Subject | Re: Unsafe code blocks |
| Date | 2025-11-21 03:03 +0000 |
| Organization | PANIX Public Access Internet and UNIX, NYC |
| Message-ID | <10fokpt$f7e$1@reader2.panix.com> (permalink) |
| References | <10f4oi1$25lkk$2@dont-email.me> <10flqou$2l1qc$1@dont-email.me> <10fmvhp$col$1@reader2.panix.com> <10fob5c$3aj3s$1@dont-email.me> |
In article <10fob5c$3aj3s$1@dont-email.me>, Arne Vajhøj <arne@vajhoej.dk> wrote: >On 11/20/2025 6:54 AM, Dan Cross wrote: >> In article <10flqou$2l1qc$1@dont-email.me>, >> Arne Vajhøj <arne@vajhoej.dk> wrote: >>> On 11/19/2025 11:02 AM, Dan Cross wrote: >>>> Further, by localizing the unsafety inside of the conversion, >>>> and using a return type that can represent failure, one can >>>> construct a _safe_ interface to do _unsafe_ conversions. >>> >>>> In contrast, `Valid` is easy to misuse, primarily by not using >>>> it at all, in which case you run the risk of raising a runtime >>>> exception, or just having an incorrect program. With either >>>> `Option` or `Result`, you are forced to contend with the error >>>> case. The programmer can't forget to check. >>>> >>>> Finally, `Valid` is very limited in its applicability: it can >>>> only be used with scalar types. At least in Rust, `Option` and >>>> `Result` are generic over essentially arbitrary types. >>>> >>>> Put another way, if the language supports something like an >>>> `Option` type, then there is no need for a special-case facility >>>> like Ada's `Valid` attribute. >>> >>> All fine. >>> >>> But you can do the same in Ada. >> >> Indeed, you can, but I never said you couldn't. My point was >> that Ada's `Valid` attribute is overly specific, underpowered, >> and ultimately unnecessary in a language that supports proper >> sum types over generics. Ada's `Valid` attribute is neither as >> general nor as robust as using an ADT like >> Option/Result/Maybe/whatever it's called in any given langauge. > >Ada's valid does exactly what it is supposed to do: check if the >output from an Unchecked_Conversion meet the constraints of the >data type. Again. Ada's `Valid` attribute is overly specific (it cannot be repurposed for other things), underpowered (it only applies to scalars and, critically, can be ignored) and unnecessary if a language has an `Option` (`Maybe`) or `Result` (`Either`) type. >It is not a replacement for Option/Result. No, it is not. Indeed, it _cannot_ be since it is a strictly weaker construct in all respects. However, `Option` or `Result`, in conjunction with something like `TryFrom`, _can_ be a replacement for `Valid`, because things like `TryFrom` and `Option`/`Result` are more general and more powerful than `Valid`. >It can be used to implement Option/Result for those >types that can be set with Unchecked_Conversion, but obviously >not for other data types. It could be, but it doesn't _need_ to be. I can see how `Valid` might be _useful_. Unfortunately, the construct seems overly rooted in some fundamental assumptions that Ada made about the world back in the 70s and 80s. It's just been passed by by the state of the art since then, as has Ada more generally. That's a pity; Ada isn't a _bad_ language, but we have better alternatives now. >A screwdriver is not good for hammering nails into wood, >but that does not mean that a screwdriver is a bad tool - it >is just not intended for that usage. Non sequitur. You seem to be arguing something nobody was saying. What I am saying is that `Valid` isn't a great tool for its intended purpose. It's like trying to turn a phillips-head screw with a flat blade driver by sorta twisting it to the side.... >Regarding the risk of not being checked, then it is inherent >in the problem - no matter the mechanism used then the developer >can chose not to do it right, because "there will always be >a valid value here". Nope, this is wrong. The whole point of a Rust-style `Option` or `Result` is that you are no longer working in terms of the generic type T, but rather a wrapper around that type; if that wrapper has the value `None` then there is no T, so the statement, 'because "there will always be a valid value here"' is, by definition, incorrect. The programmer is forced to contend with this possibility because because the programmer is working in terms of the wrapper type (the `Option` itself, say) and not the underlying value type. That said, Cloudflare had a recent production outage because somebody called `unwrap` on a `Result` that was `Err`. Yeah, that was unwise. But note that this is qualitatively different: here, the programmer _chose_ to ignore the safety guidelines and unwrap something that wasn't known to be `Ok(...)`; this was an _active_ thing. That's different than omitting a check against the valid attribute, through carelessness or ignorance; that's a _passive_ thing.. >> Also not as general. Note that in the Rust example, `Option` is >> generic over some type `T`: your example is concrete over the >> color enum, and just colocates it with a flag and a convenience >> method that returns null if the flag is false (but now all >> accesses are via reference). > >> But Ada supports generics (recall that Stepanov did the first >> implementation of the STL in Ada). You could use that to build >> an actual `Option` type that would closer to the Rust version. > >Generics is one of those Ada features that I don't like to use. That's silly. It's a powerful construct that _should_ be used, though of course it has its costs (monomorphization on concrete types, primarily). >But a generic version is attached below. > >> It would probably not be as convenient to use because Ada lacks >> Rust-style pattern matching and destructuring, but it would more >> or less obviate the need for `Valid`. > >Valid is still a way - probably the best way - to produce >the Option. Well, perhaps, provided that the concrete type embedded in the `Option` will work with `Valid`; recall that `Valid` applies only to scalars. If the `Option` wraps a product type (records, etc) then `Valid` won't work, as it's not applicable in that context. But for scalars, whether it's the "best" way or not seems highly subjective. There are probably categories of scalar values that are difficult to represent using the language's type constraints and so for which `Valid` would not meanigfully apply, but something like, `TryFrom` might. For example, one might define a newtype over integers that represents primes; the invariant is that if an instance of that type exists at all, then it is guaranteed that the contained number must be prime. This is the sort of thing you _can_ check with an explicit conversion function, but _not_ with `Valid`. A nice property of using an `Valid` in your example `Option` type, however is that because the check for validity is encapsulated in the machinery built into the `Option` itself; the programmer cannot misuse it because its use is hidden from the programmer. >[snip] - Dan C.
Back to comp.os.vms | Previous | Next — Previous in thread | Find similar
Unsafe code blocks Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-13 14:04 +0000
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-13 15:44 -0500
Re: Unsafe code blocks Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> - 2025-11-14 12:14 +0100
Re: Unsafe code blocks John Reagan <johnrreagan@earthlink.net> - 2025-11-14 11:47 -0500
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-14 14:02 -0500
Re: Unsafe code blocks Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> - 2025-11-17 09:25 +0100
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-17 14:58 -0500
Re: Unsafe code blocks Chris Townley <news@cct-net.co.uk> - 2025-11-17 20:11 +0000
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-17 15:47 -0500
Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-18 13:10 +0000
Re: Unsafe code blocks Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-14 19:32 +0000
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-14 13:55 -0500
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-14 20:00 -0500
Re: Unsafe code blocks Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-17 18:56 +0000
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-17 14:22 -0500
Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-16 02:16 +0000
Re: Unsafe code blocks Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-17 19:22 +0000
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-17 14:55 -0500
Re: Unsafe code blocks Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2025-11-17 20:33 +0000
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-17 15:55 -0500
Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-18 12:54 +0000
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-18 14:04 -0500
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-18 14:07 -0500
Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-19 16:12 +0000
Re: Unsafe code blocks Michael S <already5chosen@yahoo.com> - 2025-11-19 19:29 +0200
Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-19 19:00 +0000
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-19 12:41 -0500
Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-19 18:19 +0000
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-19 14:21 -0500
Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-19 19:49 +0000
Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-19 16:02 +0000
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-19 20:26 -0500
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-19 20:31 -0500
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-19 21:32 -0500
Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-20 11:54 +0000
Re: Unsafe code blocks Arne Vajhøj <arne@vajhoej.dk> - 2025-11-20 19:18 -0500
Re: Unsafe code blocks cross@spitfire.i.gajendra.net (Dan Cross) - 2025-11-21 03:03 +0000
csiph-web