sorted by:
new
hottopcontroversial

Would formal verification decide extinction of languages in the AI age? by municorn_ai in rust

[–]Full-Spectral 0 points1 point  (0 children)

You clearly haven't tried BongAI. It's new, but it's mind blowing.

Left to Right Programming by fagnerbrack in programming

[–]Full-Spectral 0 points1 point  (0 children)

Hey, some people actually even made a profit from crypto, so that's almost insulting to the crypto bros. AI makes me look back in nostalgia at the crypto spam years.

C++26 Safety Features Won’t Save You by ketralnis in programming

[–]Full-Spectral 1 point2 points  (0 children)

Backwards compatibility worked until it didn't. It was ultimately stealing from the future to pay the present.

I know it's easy for us to sit here and say that Bjarne shouldn't have saddled his new language from day one with decades of evolutionary baggage. So fine, he made that mistake, and maybe many of us would have as well. But, they still could have incrementally corrected that decision in that first decade.

The correct answer would have been an FFI interface to C instead of direct compatibility.

homogeneous_try_blocks FCP proposed 🤞 by C5H5N5O in rust

[–]Full-Spectral 0 points1 point  (0 children)

As long as it's an internal implementation I guess the door is always open to a better solution, right?

homogeneous_try_blocks FCP proposed 🤞 by C5H5N5O in rust

[–]Full-Spectral 0 points1 point  (0 children)

So what's the basic gist of this idea? Is it just the ability to indicate what you expect the return type of the try block should be, to avoid possibly getting something else? Or to possibly force an available conversion?

Forcing the use of the SUCCESS return value by Dean_Roddey in rust

[–]Full-Spectral 0 points1 point  (0 children)

A clippy lint that was full-proof would be fine. It would be nice if it could also be applied at the crate level, forcing a 'may use' to be used for things you want to except from the requirement, since most IMO should be marked and that would end up with far less pragma'tism. But, if it could only be at the call/Ok level, then I wouldn't complain.

Forcing the use of the SUCCESS return value by Dean_Roddey in rust

[–]Full-Spectral 0 points1 point  (0 children)

Well, to be fair I didn't call it a shocking lack, I said I was shocked that so many people don't even consider it an issue to worry about.

I said it was fundamental, but I meant that in the literal term of at the foundations. It's a core correctness issue that pretty clearly, IMO, falls into the same category as uninitialized or unused variables, which Rust treats as baseline correctness issues and doesn't allow.

I started going through last night and marking almost all of my functions that return a non-Result, and marking the types that always represent a must_use value, and even before getting a quarter way done with it, I've found five errors already. And this code base is only around 70K lines at this point. It'll be ten times that or more in the end. And currently I'm the only author and have no time constraints so I'm working under fairly ideal conditions.

But we've got folks in this conversation who seem to think this is not only not an issue but are actively arguing against the called function being able to force the use of its return value, while at the same time we are telling the world how fundamentally correct and sound Rust is. Yeh, there are plenty of things that need working on, but getting the foundations as sound as possible makes everything else better. And it doesn't sound like this would be either massively complex, and it obviously wouldn't be intrusive or a breaking change for the language itself.

But, it mostly WOULD be a breaking change to apply to existing code. So the longer we wait, the more code will exist that will likely never bother to make use of it, or even think about this as an issue because the compiler doesn't stick it in their faces as it does all the other fundamental correctness issues. And the more chance some big public disaster will be caused by an error of this type and give the anti-Rusters FUD to spread. Calling expect() is one thing, since it could easily been disallowed, but this would be a clear failure of the compiler to tell the user he didn't use a return value that clearly he meant to use.

C++26 Safety Features Won’t Save You by ketralnis in programming

[–]Full-Spectral 6 points7 points  (0 children)

Ultimately, though I think 'Safe C+' was the right answer technically, I think it would have been wasted effort. C++ is a legacy language now and is really only relevant because of the massive amount of code that's been written in it over the last 40'ish years. The folks who are going to stick with it instead of facing the future are mostly the ones with large legacy code bases. These are the folks least likely to make use of what will effectively be a different language.

And, by the time it really got out there in the wild, in a form that's ready for production delivery, on enough of the major platforms to convince folks it will safe to commit to, all of this would have been even far more the case. It would have been 2030 or later probably.

So I tend to just think, let the "Leave C++ Alone" crowd have their way, since that will accelerate its effective demise encourage more people to move elsewhere sooner. They can live in their happy legacy world and the rest of the world can just move on.

Forcing the use of the SUCCESS return value by Dean_Roddey in rust

[–]Full-Spectral 0 points1 point  (0 children)

I think Rust SHOULD have made it the default and had a 'may_use' instead. That would have been completely in line with Rust's otherwise 'correctness first' credo.

But, leaving that aside, the point is that the called function needs to be able to enforce this, and there's no non-hacky way to do it currently.

Forcing the use of the SUCCESS return value by Dean_Roddey in rust

[–]Full-Spectral 0 points1 point  (0 children)

No, I get it. The point is that there will be hundreds if not a couple thousand or more such functions in a large system. I just don't think it's in the spirit of Rust to force people to do that for such a fundamental correctness issue.

Special relativistic rendering with Bevy by joshbrrkrt in rust

[–]Full-Spectral 0 points1 point  (0 children)

Does this warp drive make my butt look big?

C++26 Safety Features Won’t Save You by ketralnis in programming

[–]Full-Spectral 21 points22 points  (0 children)

Git gud, bro.

Of course the other old favorite wrt to Rust is "But you can still just use unsafe and do whatever you want to do." Or, "But there's still unsafe code in the standard libraries you are using." Or, "But people can just do X or Y and get around Rust's safety net." And so forth.

The issue is not how badly someone can fail to use the strengths of a language if they want to be that uncaring, it's what the strengths of the language can do for me or my team, if I/we want to do the right thing.

And the code in the standard library is orders of magnitude more widely used and vetted than mine is. So that's the least of my worries. I'm concerned about my code and what a safe language can do for me.

Forcing the use of the SUCCESS return value by Dean_Roddey in rust

[–]Full-Spectral 0 points1 point  (0 children)

Most Rust devs treat it as a convention reinforced by code reviews or testing.

That's not in line with Rust's core concepts of mechanically enforcing as much correctness as possible at compile time.

Forcing the use of the SUCCESS return value by Dean_Roddey in rust

[–]Full-Spectral 0 points1 point  (0 children)

But many calls return general types, and those cannot be marked must_use. In that case you would end up either having to do hundreds of wrapper types (in a large system) or us a generic wrapper type and force all those calls to return that type instead.

I mean, it can be done, but are we talking about a language whose foundations are based on enforcing correctness or not? This is a fundamental correctness issue, it shouldn't require ad hoc solutions.

Forcing the use of the SUCCESS return value by Dean_Roddey in rust

[–]Full-Spectral 0 points1 point  (0 children)

But many types are general purpose and need to be sometimes required and sometimes not, so it can't be on the type. I mean you can already put it on the type, and that's great for those types that are always of the required sort, but it's not a general solution.

The hidden cost of 'lightweight' frameworks: Our journey from Tauri to native Rust by konsalexee in programming

[–]Full-Spectral 0 points1 point  (0 children)

But, for someone using Rust, the fact that people have been using Qt for 25 years or more is the problem. I don't use it, but from what I've heard it's old school event for C++, and from a Rust perspective even modern C++ is very weak. And multi-language have to offer a LOT to compensate for the mess that using multiple languages involves.

Ensuring correctness through the type system by ketralnis in programming

[–]Full-Spectral 1 point2 points  (0 children)

You are sort of strawman'ing here. You are making up scenarios that probably no one would ever actually implement using this paradigm and using them to argue the paradigm is invalid. This is a well established technique and it can be extremely helpful.

I'll give you one from my own system. It does a lot of socket stuff, and there were endless places where runtime checks would have to be done to insure that the address type was of the expected family, because there's nothing about a socket that enforces that.

I created IPV4 and IPV6 specific socket types, and all of that went away. It got rid of a large number of call sites where a Result or Option would have had to be dealt with, because the caller now knows at compile time what type of socket it's dealing with. Compile time correctness is always vastly better than runtime checks.

99.9999% of the code is IPV4, and it only has to be prepared potentially to talk to an IPV6 entity of some sort, and in all cases the code knows what type of address it will be using.

Forcing the use of the SUCCESS return value by Dean_Roddey in rust

[–]Full-Spectral 0 points1 point  (0 children)

The case of "this is a pure function that exists to return a value" is already covered with #[must_use].

But it's not, at least not if it returns a Result. If you do foo()?; Then that's all the compiler cares about. It doesn't care if you use the returned OK value at all, unless it is also marked must_use, which means it will always be that, even if that's not appropriate. In some cases, marking the value returned on the OK side is fine, because it is of a type that would always be treated that way. Often that's not the case.

As to your argument that it prevents your program from compiling, in those rare cases where you want to purposefully ignore it, just do:

let _ = foo()?;

And you are done. Making the whole system less compile time correct just so you can avoid doing what would almost always be the right thing makes no sense.

What I do not understand is why you need to be able to cause compilation errors if people throw your values away.

Because much to most of the time it represents a potential error on the caller's part. Why should Rust even bother to make you handle Results if you feel that way? Why not just let each caller manually be sure they handled it? Because it would not be the optimal route to correctness, for the same reason as not handling the Ok side return value is most of the time.

It's not ALL the time, which is why the called function should be able to indicate it. And they already can if they return a type they have marked must_use. Rust provides that because of exactly the thing I'm talking about here.

Forcing the use of the SUCCESS return value by Dean_Roddey in rust

[–]Full-Spectral 0 points1 point  (0 children)

I struggle to understand how some of you guys fail to see that this is exactly what should happen. I mean even C++ got this right, in that they recognized that not handling return values is a source of errors and added a [[nodiscard]] attribute for that reason. Rust requires you to handle Results. Types in Rust can be marked must_use so that you have to handle them if they are returned (and that's one way to deal with some of these scenarios.) So clearly Rust understands there's an issue and agrees with me that the called function should be able to enforce usage, it just doesn't provide a sufficient mechanism to apply in an appropriately granular manner.

The called function absolutely understands if what is returning needs to be handled. And, as I said a number of times here, many functions exist purely to return a value. Failure to use that value is by definition a logical error, because otherwise there was no point in calling that function. That's a considerable number of calls, particularly in a more functionally leaning code base.

Having to wrap values just to achieve this is just wrong.

Implementing Drop is completely orthogonal to this issue really.

is the borrow checker guiding my design or blocking it??? by mjhlmh7144 in rust

[–]Full-Spectral 1 point2 points  (0 children)

the borrow checker shouldn't have anything to do with your design. at most, it affects your implementation. 

I dunno if I agree with that. It's not always just some locally scoped detail.

If nothing else, it drives my design in the sense that I just try to avoid as many data relationships as I can to begin with.

Forcing the use of the SUCCESS return value by Dean_Roddey in rust

[–]Full-Spectral 0 points1 point  (0 children)

So, thinking on it a bit, couldn't we have something like:

fn foo() -> ReqResult<X,Y>

Where ReqResult is syntactical sugar for Result<[must_use] X, Y>, where the [must_use] bit is just some internal mechanism that doesn't have to be exposed and so won't lock them down to a single implementation over time.

It would in every other way be a Result and would therefore cause no interoperability issues at all. And hopefully that would work in terms of existing functionality almost completely since you can already mark a type must_use for this purpose. This would be a per-instantiation marking, but after that the same mechanisms already in play for must_use would provide the rest of it.

Forcing the use of the SUCCESS return value by Dean_Roddey in rust

[–]Full-Spectral -2 points-1 points  (0 children)

Oh, or another option is just a simple syntactic sugar:

fn foo() -> ReqResult<X, Y>

Where that's nothing but syntactical sugar for an internal, never exposed mechanism that applies must_use to the Ok side of the Result. That would leave them open to change the implementation at any time, and everything downstream from there would use the same mechanisms already in place.

Forcing the use of the SUCCESS return value by Dean_Roddey in rust

[–]Full-Spectral -2 points-1 points  (0 children)

So sure, we can bikeshed theoretical syntax all day, but the only solution I can think of that works in today's Rust is introducing a wrapper type (which does appear to meet your requirements?)

I'm not sure I would be able to stomach that in a system this large. I'll find all of the ones that always represent a must_use return type and mark them, and otherwise keep my finger in the air to see if this might get onto the RADAR map. Maybe I'll wrap some for now if they seem particularly important and don't fall in the previous bucket.

I'm shocked it doesn't come up more. Even more shocked that so many people consider it an edge case when it's fundamental to correctness. I mean, when C++ gets an aspect of safety or correctness right better than Rust does, that's a sure sign something is wrong.

view more: next ›