On 10-08-17 02:23 AM, Jeffrey Yasskin wrote:
'Course, there's no reason you couldn't optimize the function to
"return global_constant", but that still involves the call and
refcounting overhead. If you figure out how to solve the rodata vs
refcounting problem, you could skip the refcounting here too.
You could auto-const local calculations if you can prove they're pure,
yeah. Assuming you've compile-time access to the contributing functions,
and you're sure the user didn't lie about the purity of anything. Might
be risky. Maybe only do so when you're talking about built-in language
primitives?
(This is part of the conversation about constants: do we want to go the
D route and say "the compiler will feel free to load and call
declared-pure functions at compile time when calculating anything it
feels is constant? Or *just* stick with language-provided pure things
like binops and value constructors?)
This is purely a syntactic issue, isn't it? You can compile either
syntax to either implementation. IIRC, Ruby and D both allow one to
call a 0-argument function without parentheses.
Syntax often intersects with other matters (say, type inference):
type color = tag(red(), green(), blue());
auto c = red;
Is c of type color, or type (fn () -> color)? Currently it's the latter.
I'll admit it's a minor detail, but one worth paying a touch of
attention to while deciding what to do here.
It wouldn't have to be done in the frontend even if the language
guarantees it. You'd just have to run a couple passes even at -O0. It
only needs to be done in the frontend if you allow these constants to
be used as part of a type like C++ does.
Ah, but constrained types *do* support (at present) literal args to
constraints. Generalizing these to const-exprs is a natural step :)
It's a la C++. C99 requires static initializers to be compile-time
constant in 6.7.8p4.
Ah, whoops. I always trip up on this sort of thing because of the VLA
support in C99. Makes me think they absorbed more than they did.
This bit is separable. I think it'd make sense to say that constants
in one crate are runtime values from another crate. If you start
inlining functions across crate boundaries, you can re-use the same
checking mechanism to inline constants. You'd want a way to let the
user control this in case they actually want the crate to be
upgradeable without relinking.
Indeed so. I was mostly just wondering aloud which mechanisms felt
tasteful vs. distasteful to those reading. Ocaml for example uses a CHF
of the module signature (md5 I think) and ... I've heard zero users
complain, though at least *some* type theorists think it's an
abomination. C++ does name mangling but with nominal rather than
structural types, so it's the worst of both worlds (unsafe, yet
pretending to be brittle). Umm...
There are a few options, of course :) I made the crate graph acyclic at
least in part to support CHF-based signature checking.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
