Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Type inference woes

Name: Anonymous 2019-01-25 15:56

CONSIDER this Rust code that a reasonable human being might try to write:

fn add<T>(a: T, b: T) -> T {
return a + b;
}

If you try to compile that, you’ll get an error like this:

:1:25: 1:30 error: binary operation `+` cannot be applied to type `T`
What you actually have to write is something like this:

use std::ops::Add;
fn add<T: Add>(a: T, b: T) -> T::Output {
return a + b;
}

Now it typechecks correctly.

This seems a little ridiculous. The compiler already knew that T had to be a type that supports addition — it just told me that. So why am I spelling it out?

Name: Anonymous 2019-01-28 15:19

>>43
Language primitives:
1.Require no library/header/method import and processing time associated thereof.

2.Are able to be optimized further than library construct, within the compiler.
Many optimizations and code transformations are simplified if internally available.

3.Secure the existence of libraries using the code, since library changes and bugs can't affect them. You can't just have a situation where is a need to upgrade to Addition2.0 or your code is now incompatible.

4.Language primitives reduce syntax clutter and boilerplate, as demonstated in this thread, you don't need to explicitly import anything or adapt your code to call library/method/functions, since the construct is native to the language.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List