Custom methods won’t have the benefit of being dealt with as if they shared specific semantics, such as being treated as safe methods or idempotent, but ultimately that’s just an expected trait that anyone can work with.

In the end, specifying a new standard HTTP method like QUERY extends some very specific assurances regarding semantics, such as whether frameworks should enforce CRSF tokens based on whether a QUERY has the semantics of a safe method or not.

However, we’re still implementing IPv6, so how long until we could actually use this?

We can already use custom verbs as we please: we only need to have clients and servers agree on a contract.

What we don’t have is the benefit of high-level “batteries included” web frameworks doing the work for us.

Yeah, the quality on Lemmy is nowhere (…)

Go ahead and contribute things that you find interesting instead of wasting your time whining about what others might like.

So far, all you’re contributing is whiny shitposting. You can find plenty of that in Reddit too.

Why restrict to 54-bit signed integers?

Because number is a double, and IEEE754 specifies the mantissa of double-precision numbers as 53bits+sign.

Meaning, it’s the highest integer precision that a double-precision object can express.

I suppose that makes sense for maximum compatibility, but feels gross if we’re already identifying value types.

It’s not about compatibility. It’s because JSON only has a number type which covers both floating point and integers, and number is implemented as a double-precision value. If you have to express integers with a double-precision type, when you go beyond 53bits you will start to experience loss of precision, which goes completely against the notion of an integer.

Ok.

It’s very hard for “Safe C++” to exist when integer overflow is UB.

You could simply state you did not read the article and decided to comment out of ignorance.

If you spent one minute skimming through the article, you would have stumbled upon the section on undefined behavior. Instead, you opted to post ignorant drivel.

I wouldn’t call bad readability a loaded gun really.

Bad readability is a problem cause by the developer, not the language. Anyone can crank out unreadable symbol soup in any language, if that’s what they want/can deliver.

Blaming the programming language for the programmer’s incompetence is very telling, so telling there’s even a saying: A bad workman always blames his tools.

Well, auto looks just like var in that regard.

It really isn’t. Neither in C# nor in Java. They are just syntactic sugar to avoid redundant type specifications. I mean things like Foo foo = new Foo();. Who gets confused with that?

Why do you think IDEs are able to tell which type a variable is?

Even C# takes a step further and allows developer to omit the constructor with their target-typed new expressions. No one is whining about dynamic types just because the language let’s you instantiate an object with Foo foo = new();.

C++ continues to be the dumping ground of paradigms and language features. This proposal just aims to add even more to an overloaded language.

I think you could not be more wrong even if you tried, and you clearly did not even read the proposal you’re commenting on.

This proposal aims to basically create an entirely different programming language aimed at being easy to integrate in extsting codebases. The language just so happens to share some syntax with C++, but you definitely can’t compile it with a C++ compiler because it introduces a series of backwards incompatible changes.

It’s also absurd how you complain about introducing new features. Can you point out any language that is not absolutely dead that is not introducing new features with each release?

C++ programmers mocked languages for being dynamically typed then they introduced auto (…)

I’m sorry, you are clearly confused. The auto keyword is not “dynamically typed”. It is called “auto” because it does automatic type deduction. It is syntactic sugar to avoid having to explicitly specify the type name in places the compiler knows it already. Do you understand what this means?

Your comment sounds like trolling, frankly.

I feel like this will have zero protection against

Zero protections against what? Against the programmer telling the program to do something it shouldn’t? Not programming language does that. If you resort to this sort of convoluted reasoning, the same hypothetical programmer can also swallow all exceptions.

The main problem you’re creating for yourself is that you’ve been given an open-ended problem but instead prefer to not look for solutions.

Have you ever worked at large old corporation?

I’m not sure you understand that it’s way more than “large old corporations” that use it. Everyone uses it, from large multinationals to small one-taxi shops, and even guys like you and me in personal projects. This has been going on for years. I really don’t know what led you to talk about large old corporations, seriously.

The problem is that you need some support from the language to make it easy to deal with.

Nonsense.

if (result.isSuccess()) {
    do_something(result.value);
}
else {
   handle_error(result error);
}

I mean, yeah, if your language does not support error values, do not use them.

Nonsense. If adopting info of the many libraries already available is not for you, it’s trivial to roll your own result type.

Even if that was somehow unexplainably not an option, even the laziest of developers can write a function to return a std::tuple or a std::pair and use structured binding.

It’s used because the ones who use it have enough money to pay for any problems that may arise from it’s use, (…)

That’s laughable. Literally the whole world uses it. Are you telling me that everyone in the world just loves to waste money? Unbelievable.

That way we’ll just find maintainers went near extinct over time, just like COBOL developers that are as rare as they are expensive.

Care to take a shot at figuring out why COBOL is still used today?

I mean, feel free to waste your time arguing for rewrites in your flavor of the month. That’s how many failed projects start, too, so you can have your shot at proving them wrong.

But in the meantime you can try to think about the problem, because “rewrite it in Rust” is only reasonable for the types who are completely oblivious to the realities of professional software development.

You’d have had me ignore them all and keep using C for everything.

Please tell me which language other than C is widely adopted to develop firmware.

You’re talking about so many up-and-comers during all these decades. Name one language other than C that ever came close to become a standard in firmware and embedded development.

Right.

Yeah, because the new tools are never actually better, right?

Well, yes. How many fads have come and went? How many next best things already died off? How many times have we seen the next best thing being replaced by the next best thing?

And yet, most of the world still runs on the same five languages: C, Java, C++, C#, JavaScript.

How do you explain that, with so many new tools being so much better than everything?

Might it be because fanboys tend to inflate their own definition of “actually better”, while turning a blind eye to all the tradeoffs they need to pretend aren’t there?

If you had a grasp on the subject you’d understand that it takes more than mindlessly chanting “tools” to actually get tangible improvements, and even I’m that scenario often they come with critical tradeoff.

It takes more than peer pressure to make a case for a tool.

That seems like a poor attitude imo.

Why do you believe that forcing something onto everyone around you is justifiable? I mean, if what you’re pushing is half as good as what you’re claiming it to be, wouldn’t you be seeing people lining up to jump on the bandwagon?

It’s strange how people push tools not based on technical merits and technological traits, but on fads and peer pressure.

Clearly Rust is a conspiracy.

Anyone in software development who was not born yesterday is already well aware of the whole FOMO cycle:

1. hey there’s a shiny new tool,
2. it’s so fantastic only morons don’t use it,
3. oh god what a huge mistake I did,
4. hey, there’s a shiny new tool,