Intrinsic semantics

[Aatch]

Kinda tired of intrinsics causing so much tangential discussion. This makes the current system concrete. If you feel strongly about some other way, please, please write an RFC for that way so it can be the defined semantics.

Rendered

[nikomatsakis]

This RFC seems good, if we want intrinsics (I've not read it in super detail). However, I have been thinking of floating a proposal to remove intrinsics altogether, in fact, and simply have lang items only. This is still my preference: lang items and intrinsics overlap in purpose quite a bit, but lang items are significantly more general, and it seems like the better mechanism.

[nikomatsakis]

Note that I think this RFC really belongs to @rust-lang/lang and not @rust-lang/compiler, so I'm going to remove the T-compiler tag.

[pnkfelix]

So... this RFC as written is just attempting to codify one aspect of the current intrinsic system, since it explicitly makes no changes at all?

@nikomatsakis any reason to not just accept this in the short tern, since a later hypothetical RFC removing intrinsics will supercede it?

(Also, won't you hit the same bike shed with the intrinsics encoded as lang items? Seems like if we want to codify this "only callable" idea, then we'd need a concept to capture that anyway

[nikomatsakis]

Hmm, yes, I initially assumed the RFC went a bit further than it did. I am fine with it in terms of documenting existing policy.

[eddyb]

To expand on the lang item idea @nikomatsakis described somewhere else:
Instead of having a dummy body such as:

#[lang = "intrinsic.move_val_init"]
pub unsafe fn move_val_init<T>(dst: *mut T, src: T) {
    unreachable!()
}

We could make the intrinsics "call themselves":

#[lang = "intrinsic.move_val_init"]
pub unsafe fn move_val_init<T>(dst: *mut T, src: T) {
    move_val_init(dst, src)
}

While this looks like infinite recursion, remember that direct calls to intrinsics are expanded in-place.

So what this definition would do is create a wrapper function for the intrinsic operation, and you can get the wrapper function by coercing move_val_init to a fn pointer type.

Otherwise, its type is a function item type, containing the item ID allowing calls to be expanded in-place, in a more flexible way than the existing ExprPath-based logic in trans.

[nikomatsakis]

@eddyb hey, that's clever :)

[pnkfelix]

where have i seen that before ... ;)

[petrochenkov]

where have i seen that before ... ;)

Don't our own built-in operators do the same thing? They are intrinsics too in some sense.
https://github.com/rust-lang/rust/blob/master/src/libcore/ops.rs#L616

[nikomatsakis]

🎺 Hear ye, hear ye! 🎺 This RFC is entering final comment period.

[nikomatsakis]

Huzzah! The language design subteam has decided to accept this RFC.

[target-san]

If you ask me, I'd rather use extern-like approach, with no body. Either unreachable!(), empty body or self-invocation are all confusing. Intrinsics don't have known body definable in terms of Rust language.

[eddyb]

@target-san I would argue that self-invocation is a sane definition (for the wrapper function that you would get with an indirect call to an intrinsic).