Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Rust 1.20

blog.rust-lang.org

Post reply on HN
Print view View original

81–90 of 277 posts

Re: Announcing Rust 1.20

#81

Post by fish_fan »

msbarnett wrote: post #74
jeffdavis wrote: post #65

I've been having a little trouble using rust for a little project: I need a tree with uplinks (meaning there are cycles). I asked on IRC a couple times and I think what I need is a weak reference inside a refcell, but it's not very easy to make it work cleanly. For one thing, it doesn't look like refcell works well with traits (the nodes in the tree are traits, not plain structs). I'm a bit frustrated because this is…

> I am imagining a special way to construct cyclical structures where everything inside would have the same lifetime and be destructed at once. The simple way to do that would be to allocate an array, and use indices into the array rather than pointers/references. Doing it with pointers isn't so much harder in Rust than C as it is that Rust is making you deal with how hard it is to get this right , whereas in C the c…

While it may be simpler, it also removes any safety that rust adds. I'd imagine you'd get more mileage out of just using pointers and unsafe blocks liberally to get lifetime checking where you can.

Re: Announcing Rust 1.20

#82

Post by fish_fan »

a_humean wrote: post #43
pcx wrote: post #29

Associated functions and associated constants sound so yum! That's one thing I would love to have in Flowtype. But classes seem to serve that use case well enough.

You get something similar to with static methods and properties on class definitions. In plain ES2017-ish class syntax: class Test { static value = 1; static someStaticMethod = () => { return 5; } } console.log(Test.value) // 1 console.log(Test.someStaticMethod()) // 5 Edit: Sorry, this actually a Stage 3 TC39 feature. Not sure if you can use it with flowtype (I think you can), but you might be able to if you enable…

Note, I think in spite of being in stage 3 the syntax and obvious cases seem to be largely unlikely to change. It certainly improves react quite a bit: you can define the proptypes and default values inside the class rather than after.

Re: Announcing Rust 1.20

#83

Post by circlingthesun »

comex wrote: post #75
jeffdavis wrote: post #65

I've been having a little trouble using rust for a little project: I need a tree with uplinks (meaning there are cycles). I asked on IRC a couple times and I think what I need is a weak reference inside a refcell, but it's not very easy to make it work cleanly. For one thing, it doesn't look like refcell works well with traits (the nodes in the tree are traits, not plain structs). I'm a bit frustrated because this is…

Regarding traits: you can have Rc (by casting from Rc ), but not RefCell . The reason is that Rc is a pointer, so the size of Rc can be constant regardless of the size of the type implementing the trait. But if you actually want a weak reference inside a refcell (as opposed to the other way around), RefCell > should work fine. Also consider the Cell type, which has a more limited API than RefCell but zero overhead. R…

> Regarding everything being destructed at once: that’s called an arena

Thats such a great name :)

Re: Announcing Rust 1.20

#84

Post by kccqzy »

copx wrote: post #15
kibwen wrote: post #6

Earlier quoted context omitted.

You've misread the announcement; Rust has had associated functions since time immemorial. Associated consts aren't class variables, because constants can't vary (that's sort of the whole point of constants...). Rust also doesn't have classes in any recognizable sense (we can argue all day about whether Rust supports "OOP", but the separation of data and behavior into structs and impls respectively pretty thoroughly s…

>Associated consts aren't class variables, because constants can't vary That's why I wrote "limited version of". Rust's "associated constants" are a subset of C++'s class variables feature. Namely you can only have variables qualified "const" i.e. constants. >Rust also doesn't have classes in any recognizable sense What? If you have instantiatable abstract data types with associated methods you have a "class". Callin…

By that definition, Haskell is an OOP language too, because Haskell has type classes (traits/interfaces) too, and you can have associated methods/associated types too.

Re: Announcing Rust 1.20

#85

Post by kzrdude »

tatterdemalion wrote: post #26
sevensor wrote: post #18

Not a Rust programmer, so the answer to this question may be in TFM -- Rust has floats, but it doesn't make available constants for inf and NaN? Are you not guaranteed IEEE754 floats? const NAN: f32 = 0.0f32 / 0.0f32; const INFINITY: f32 = 1.0f32 / 0.0f32; Or is that just for the sake of example?

The consts are currently defined in modules with the same name as the type, `std::f32::NAN;`. This feature allows them to be associated with the type itself - `f32::NAN`. A small convenience.

It's more than a small convenience. It's a big feature that we can use when designing traits and APIs.

Re: Announcing Rust 1.20

#86

Post by mikeash »

evincarofautumn wrote: post #77
kbenson wrote: post #13

> An unstable sort could provide this result, but could also give this answer too: It might just be me, but using "this" twice in the same sentence to refer to two distinct items, one a prior example and one an upcoming example, is somewhat odd. That said, I understood it perfectly fine, it just caused me to stop and ponder the wording for a moment. The following might be more clear: An unstable sort could provide th…

In case anyone’s curious, this is called discourse deixis[1]. It’s a frequent source of errors for non-native English speakers, because in many languages, you use “that” to refer to an example that follows, but English is unusual in that it generally uses “this” for the future and “that” for the past. So that[2] sounds wrong: This[3] probably screwed you up. The somewhat confusing thing is that “this” is also used fo…

Wow, nice example. It's so good I initially thought I had completely missed something or your comment had suddenly become incoherent.

Re: Announcing Rust 1.20

#87

Post by pjmlp »

circlingthesun wrote: post #83
comex wrote: post #75

Earlier quoted context omitted.

Regarding traits: you can have Rc (by casting from Rc ), but not RefCell . The reason is that Rc is a pointer, so the size of Rc can be constant regardless of the size of the type implementing the trait. But if you actually want a weak reference inside a refcell (as opposed to the other way around), RefCell > should work fine. Also consider the Cell type, which has a more limited API than RefCell but zero overhead. R…

> Regarding everything being destructed at once: that’s called an arena Thats such a great name :)

It is quite common name for memory pools.

Re: Announcing Rust 1.20

#88

Post by pjmlp »

copx wrote: post #2

"Associated functions" = class methods "Associated constants" = limited version of class variables Rust keeps approaching C++'s feature set.. I am amazed that the above wasn't in Rust to begin with, though. Can't think of any other languages which has classes but no class methods/variables.

Regarding languages with OOP support, but lacking class methods.

- Object Pascal (in the TP days)

- Modula-3

- Oberon, Oberon-2, Active Oberon, Oberon-07

- Component Pascal

You need to resort to plain functions/procedures instead.

Re: Announcing Rust 1.20

#89

Post by slavik81 »

GolDDranks wrote: post #30
slavik81 wrote: post #22

Is f32 the only suffix for float literals? That seems really noisy compared to just f in C. I'm mostly concerned about vector and matrix declarations, but even in the examples given, 1.0f32 / 0.0f32 looks like a mess of numbers compared to 1.f / 0.f;

Yes, it is, for 32-bit floats. However, most of the time you don't need to specify that, because it will be inferred from the context. (And if it isn't you can introduce hints like `let growth_rate: f32 = 50.0/140.0`) Also, Rust supports having _ anywhere in number literals. Some may argue that it makes things even noisier, but it helps to separate the suffix from the value itself: `100.0_f32`.

Very nice. As you say, it doesn't just cast at the end, but actually uses the type through the whole calculation! To illustrate the difference:

Rust:

    fn main() {
      let a: f32 = 1e7 + 0.5 + 0.5;
      let b: f32 = 1e7f32 + 0.5f32 + 0.5f32;
      println!("{}", a==c); // true
    }
C:

    #include 
    int main() {
      float a = 1e7 + 0.5 + 0.5;
      float b = 1e7f + 0.5f + 0.5f;
      printf("%s\n", a==b ? "true" : "false"); // false
    }
That's awesome. I'm totally fine with an annoying suffix like f32 if I never actually need to use it. While f might be a nicer suffice than f32, no suffix is even better.

Re: Announcing Rust 1.20

#90

Post by skariel1 »

fish_fan wrote: post #81
msbarnett wrote: post #74

Earlier quoted context omitted.

> I am imagining a special way to construct cyclical structures where everything inside would have the same lifetime and be destructed at once. The simple way to do that would be to allocate an array, and use indices into the array rather than pointers/references. Doing it with pointers isn't so much harder in Rust than C as it is that Rust is making you deal with how hard it is to get this right , whereas in C the c…

While it may be simpler, it also removes any safety that rust adds. I'd imagine you'd get more mileage out of just using pointers and unsafe blocks liberally to get lifetime checking where you can.

It is still safer than c, as it will not allow any segfaults. The only thing that can happen is a runtime error but no memory corruption so it is more akin to say Java or Go
Post reply on HN