Re: [rust-dev] This Week in Rust

[Corey Richardson]

Been super busy, but there's some good stuff in store:
http://blog.octayn.net/blog/2014/06/09/future-of-twir/

On Sun, Jul 27, 2014 at 9:46 AM, Nathan Typanski  wrote:
> It's moved here , although there hasn't been
> an update since 15 July.
>
> Nathan
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev



-- 
http://octayn.net/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Older RFCs for discussion next week

[Steve Klabnik]

I closed 117, so it shouldn't be on the docket anymore.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] This Week in Rust

[Nathan Typanski]

It's moved here , although there hasn't been
an update since 15 July.

Nathan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] Older RFCs for discussion next week

[Nick Cameron]

Hi, here are the recommendations for discussion at next weeks meetings.

As usual, if you have comments on any of these RFCs, please add them to the
discussion on the PR; please don't reply to this message.

In the future the primary method of sending this message will be via our
discourse instance at discuss.rust-lang.org (technical problems prevented
that this week).

Cheers, Nick


Proposed for discussion at Rust meeting
---


https://github.com/rust-lang/rfcs/pull/136 - Ban private items in public
APIs - glaebhoerl
Not much to add to the title. For example using a private struct as a
type in a public function.
We have a lint for part of this already.
Apparently this is used as a hack for some kind of fine-grained privacy
for traits. Seems like we should address that properly.
Mostly negative feedback, but (I think) only because of the hacks it
would break.
Discuss again (previously discussed last week)

https://github.com/rust-lang/rfcs/pull/114 - Unboxed closures - nmatsakis
A lot of discussion, pretty much all about the details. General
sentiment that we want this.
Recommend we accept - is this the right RFC to accept, I've not  really
been keeping track - pnkfelix, pcwalton - is there something  which
supersedes this? I think this needs a small update to reflect some  of the
later comments.

https://github.com/rust-lang/rfcs/pull/117 - Rename unsafe to trusted -
stevelabnik
Loads of opinion in the thread (162 comments!). Note that Niko has an
upcoming RFC (127, below) with the concept of unsafe/trusted traits where
the  keyword  `trusted` makes a lot more sense than `unsafe`, so we could
save a  keyword here.

https://github.com/rust-lang/rfcs/pull/127 - Opt-in builtin traits, take 2:
default and negative impls - nmatsakis
Unsafe (trusted) traits (see also 117, above) which express an
invariant to the compiler and default impls - which must be opted out of,
rather than in.

https://github.com/rust-lang/rfcs/pull/132 - UFCS - nmatsakis
Universal function call syntax. Use ::Foo syntax for
specifying the trait as well as the concrete type for a function call.
Previously discussed as an older RFC.

https://github.com/rust-lang/rfcs/pull/135 - where clauses - nmatsakis
Allow specifying bounds on type parameters in a where clause as well as
inline. This is more expressive and neater in the presence of many type
parameters or bounds.
Mostly positive feedback. Some worries around having inline bounds and
where clauses. Some worries about the 'multiple dispatch' part of the
proposal.


Proposed for discussion at triage
-


https://github.com/rust-lang/rfcs/issues/121 - some questions about the RFC
process - pnkfelix
These need answers for clarification on the process.

https://github.com/rust-lang/rfcs/issues/158 - Should we track incomplete
ideas here instead of in the rust issue tracker? - erikt
I think the answer is 'use discourse'. We should make sure that is the
answer, make it official in the thread and perhaps add some text to the RFC
repo readme, then close.

https://github.com/rust-lang/rfcs/pull/172 - Exponentiation syntax sugar -
SiegeLord
Sugar for the pow function.
Backwards compatible.
Recommend close and/or postpone.

https://github.com/rust-lang/rfcs/pull/174 - value type parameters - zoxc
Parameterise by values as well as types.
Recommend postpone.

https://github.com/rust-lang/rfcs/pull/175 - Field offsets - zoxc
I don't understand very well what is proposed, sorry.
Recommend postpone or close - not great motivation, doesn't seem to
merit prioritisation before 1.0.



Discussed and postponed for more feedback
-

https://github.com/rust-lang/rfcs/pull/101 - Allow multiple (fixed-size)
subslices borrows in one pattern - krdln
Allows matching several parts of a vec in one pattern. Adds `xs..n`
syntax to match a fixed size slice (and changes variable sized slice
pattern syntax to `xs..` from `..xs`).
Not much feedback - all positive or corrected later to be positive.
Seems like a small generalisation with no downsides.
If we change the syntax as recommended for existing patterns (i.e.,
`..xs` to `xs..`) then the rest should be backwards compatible, I think.

https://github.com/rust-lang/rfcs/pull/116 - Feature gate import shadowing
- Kimundi
Forbid or deprecate name collision of imported names.
Positive feedback.
Recommend: lets do this! Might need to tidy up the RFC, but nothing
major (hopefully). Need to decide whether to depricate via a feature gate
or just get rid. Would be good to assess how much damage this will cause.

https://github.com/rust-lang/rfcs/pull/129 - refine the `asm!` extension -
pczarn
A string/format! based method of doing inline asm.
Not much feedback.
Seems like we could do better with our inline asm, not sure if this is
the right approach.
  

Re: [rust-dev] Implementation of traits in Rust: could it be dynamic?

[Lionel Parreaux]

I see. Thanks for the links, Greg Morrisett's notes are a great survey of
possible approaches to this problem.
It is funny because I had also come to the conclusion that JIT was the
neater solution, as long as JIT is available with the runtime... and you
don't have to implement it -- I guess it's even more complex than doing
runtime dictionary passing.
Has there been experiments using LLVM's JIT to implement polymorphism in
Rust? I'm not sure about the cost of JIT, though. Maybe it would not make
sense in Rust. Well, at least there should still be the static
monomorphization option.



2014-07-26 5:31 GMT+02:00 Patrick Walton :

> On 7/25/14 8:26 PM, Patrick Walton wrote:
>
>> Uniform value representations work well too (as
>> OCaml shows), but of course you'll pay a performance cost for that.
>>
>
> Oh, note that Greg's notes are a little bit out of date when discussing
> the performance tradeoffs of uniform value representation. On 64 bit (and
> even on 32 bit) you can do NaN-boxed "fatvals" [1] (scroll down to
> "Mozilla's New JavaScript Value Representation") which avoid having to box
> every floating point value.
>
> Patrick
>
> [1] http://evilpie.github.io/sayrer-fatval-backup/cache.aspx.htm
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

[rust-dev] This Week in Rust

[Zoltán Tóth]

What happened to it?
I can not live without it.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev