On Sun, Feb 02, 2014 at 10:30:51AM +0100, Benjamin Herr wrote:
... while C# apparently compromises and puts the type parameters between
the function name and value parameter list, but leaves the bounds for
later:
public static bool ContainsT(IEnumerableT collection, T item)
Just because Any is a trait doesn't mean it doesn't break parametricity.
Look at this:
http://static.rust-lang.org/doc/master/src/std/home/rustbuild/src/rust-buildbot/slave/doc/build/src/libstd/any.rs.html#37-63
Because we have `implT: 'static Any for T`, it can be used with *any
type* (except
Actually this isn't the case.
fn fooT: Any(t: T) - TypeId {
t.get_type_id()
}
compiles just fine, but
fn barT(t: T) - TypeId {
t.get_type_id()
}
fails with error: instantiating a type parameter with incompatible type
`T`, which does not fulfill `'static`. Just T does not imply T:
On Mon, Feb 3, 2014 at 5:20 PM, Eric Reed ecr...@cs.washington.edu wrote:
Actually this isn't the case.
fn fooT: Any(t: T) - TypeId {
t.get_type_id()
}
compiles just fine, but
fn barT(t: T) - TypeId {
t.get_type_id()
}
fails with error: instantiating a type parameter with
On Mon, Feb 3, 2014 at 11:20 PM, Eric Reed ecr...@cs.washington.edu wrote:
Actually this isn't the case.
fn fooT: Any(t: T) - TypeId {
t.get_type_id()
}
compiles just fine, but
fn barT(t: T) - TypeId {
t.get_type_id()
}
fails with error: instantiating a type parameter with
On Sun, 2014-02-02 at 14:45 +1300, Nick Cameron wrote:
- The change adds boilerplate and nomenclature that is likely
unfamiliar to our target audience - 'for all' is well known to
functional programmers, but I believe that is not true for most users
of C++ (or Java). Being closer to the
On 02/01/2014 11:39 PM, Corey Richardson wrote:
```
forallT, U struct Foo { ... }
forallT, U impl TraitT for FooT, U { ... }
forallT, U fn foo(...) { ... }
```
Why not
```
fn foo: pub unsafe T, U = (f: |T| - U, arg: T) - U { f(arg) }
struct foo: T, U = { ... }
impl Foo: T, U = TraitT { ... }
I'm not a huge fan of this proposal. It makes declarations longer, and it
removes the visual consistency of FooT,U everywhere, which I think
introduces its own pedagogical issue.
The recent addition of default type parameters, though, makes me think
there's a reasonable change that increases
After sleeping on it I'm not convinced that this would be a net improvement
over our current situation. With a few caveats I'm really rather happy with
the syntax as it is.
On Sun, Feb 2, 2014 at 8:55 AM, Jason Fager jfa...@gmail.com wrote:
I'm not a huge fan of this proposal. It makes
On Sun, Feb 2, 2014 at 6:08 PM, Benjamin Striegel ben.strie...@gmail.comwrote:
After sleeping on it I'm not convinced that this would be a net
improvement over our current situation. With a few caveats I'm really
rather happy with the syntax as it is.
On Sun, Feb 2, 2014 at 8:55 AM, Jason
Also after sleeping on it I'm not as big of a fan of this proposal.
But, I find the idea raised earlier of having generic blocks to
group implementations etc that have the same implementation nice.
Fully backwards compat though, so I'm not going to worry about it.
Hey all,
bjz and I have worked out a nice proposal[0] for a slight syntax
change, reproduced here. It is a breaking change to the syntax, but it
is one that I think brings many benefits.
Summary
===
Change the following syntax:
```
struct FooT, U { ... }
implT, U TraitT for FooT, U { ... }
On Feb 1, 2014, at 2:39 PM, Corey Richardson co...@octayn.net wrote:
The immediate, and most pragmatic, problem is that in today's Rust one cannot
easily search for implementations of a trait. Why? `grep 'impl Clone'` is
itself not sufficient, since many types have parametric polymorphism. Now
May as well throw my 2 cents in.
This is a pretty nice idea (I've always found 'implT' to be particularly
confusing anyway). It does loose a nice property, though. Previously, there
was a nice parallelism between
struct FooT
and
let foo: FooT
and so the syntax was quite obvious
First of all, why a new keyword? Reusing `for` here would be totally
unambiguous. :P And also save us from creating the precedent of multi-word
keywords.
Secondly, currently Rust has a philosophy of use-follows-declaration (i.e.
the syntax for using something mirrors the syntax for declaring it).
On Sat, Feb 1, 2014 at 3:06 PM, Benjamin Striegel ben.strie...@gmail.comwrote:
Another point in favor of this plan is that it would eliminate the need to
put type parameters directly after the `impl`, which to be honest *is*
pretty weird and inconsistent with the rest of the language. But I'm
Placing type bounds before the name of the thing you are trying to declare
feels unnatural to me. And the generic block is far too much boilerplate!
How about supporting type aliases as Scala does? So you write:
type MyT = Clone + Eq
fn fooMyT, U(t: T, u: U) - …
and the 'type' is just an
How about supporting type aliases as Scala does?
In theory I think that should be achievable today, using trait inheritance:
trait MyT : Clone, Eq {}
...at least, I *think* we allow multiple trait inheritance. Not sure what
the syntax is!
On Sat, Feb 1, 2014 at 6:12 PM, Vladimir
It seems to use a '+' instead of ','.
On Sat, 1 Feb 2014, Benjamin Striegel wrote:
How about supporting type aliases as Scala does?
In theory I think that should be achievable today, using trait inheritance:
trait MyT : Clone, Eq {}
...at least, I *think* we allow multiple trait
On Sat, Feb 1, 2014 at 6:12 PM, Vladimir Lushnikov
vladi...@slate-project.org wrote:
Also, reusing 'for' would be confusing as well, because you expect a loop
there, not a generic type bound. How about 'any':
any is a super useful identifier and is already used. I do not want to
reserve it.
```
forallT, U struct Foo { ... }
forallT, U impl TraitT for FooT, U { ... }
forallT, U fn foo(...) { ... }
```
I’m new to rust, so maybe this doesn’t make sense, but would it make sense to
have a variation of this syntax to make implementing related traits and
functions more DRY?
On Sat, Feb 1, 2014 at 6:24 PM, Eric Reed ecr...@cs.washington.edu wrote:
Responses inlined.
Hey all,
bjz and I have worked out a nice proposal[0] for a slight syntax
change, reproduced here. It is a breaking change to the syntax, but it
is one that I think brings many benefits.
Summary
On 02/01/2014 02:59 PM, Benjamin Striegel wrote:
Yes, and I don't have a solution for that.
Well, it's not like we don't already stumble here a bit, what with
requiring :: instead of just . Not sure how much other people
value the consistency here.
Yeah, the existing solution is bad, and
On Sat, Feb 1, 2014 at 6:31 PM, Corey Richardson co...@octayn.net wrote:
On Sat, Feb 1, 2014 at 6:24 PM, Eric Reed ecr...@cs.washington.edu wrote:
Again, I strongly disagree here.
There IS only one function foo. Some of it's arguments are types. foo's
behavior *does not change* based on the
On Sat, Feb 1, 2014 at 5:39 PM, Corey Richardson co...@octayn.net wrote:
A deeper, more pedagogical problem, is the mismatch between how `struct
Foo... { ... }` is read and how it is actually treated. The straightforward,
left-to-right reading says There is a struct Foo which, given the types
forallT:ByteStream, U {
impl BinaryEncoderT for MyStructU { … }
impl BinaryDecoderT for MyStructU { … }
}
comex mentioned the idea of a generic module. That would be interesting. I
like that idea better then this.
I also like how it breaks across lines:
forallT, U
Hi,
On 01/02/2014 22:58, Corey Richardson wrote:
I'd be equally happy with for instead of forall.
+1 on not using forall, it sounds confusing and is actually quite a bit to type
considering how frequent these things are.
As an alternative to for I would want to throw be and use into the mix.
I prefer the existing syntax.
- As pointed out above, there are solutions to the non-grep-ability.
- The change adds boilerplate and nomenclature that is likely unfamiliar to
our target audience - 'for all' is well known to functional programmers,
but I believe that is not true for most users of
I'm going to respond to Any and size_of separately because there's a
significant difference IMO.
It's true that Any and trait bounds on type parameters in general can let
function behavior depend on the passed type, but only in the specific
behavior defined by the trait. Everything that's not a
On Sat, Feb 1, 2014 at 9:27 PM, Eric Reed ecr...@cs.washington.edu wrote:
I wasn't aware of mem::size_of before, but I'm rather annoyed to find out
we've started adding bare A - B functions since it breaks parametricity.
I'd much rather put size_of in a trait, at which point it's just a weaker
On 2/1/14 6:43 PM, Daniel Micay wrote:
On Sat, Feb 1, 2014 at 9:27 PM, Eric Reed ecr...@cs.washington.edu wrote:
I wasn't aware of mem::size_of before, but I'm rather annoyed to find out
we've started adding bare A - B functions since it breaks parametricity.
I'd much rather put size_of in a
On Sat, Feb 1, 2014 at 9:46 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 2/1/14 6:43 PM, Daniel Micay wrote:
On Sat, Feb 1, 2014 at 9:27 PM, Eric Reed ecr...@cs.washington.edu
wrote:
I wasn't aware of mem::size_of before, but I'm rather annoyed to find out
we've started adding bare A
On 2/1/14 6:50 PM, Daniel Micay wrote:
This could be restricted to `unsafe` code by making reflection
features `unsafe` and mandating that safe functions must compile for
types meeting the bounds.
The `size_of` functionality is absolutely required to have any hope of
writing smart pointers and
Well there's only 260 uses of the string size_of in rustc's src/
according to grep and only 3 uses of size_of in servo according to
GitHub, so I think you may be overestimating its usage.
Either way, I'm not proposing we get rid of size_of. I just think we should
put it in an automatically
On Sat, Feb 1, 2014 at 10:12 PM, Eric Reed ecr...@cs.washington.edu wrote:
Well there's only 260 uses of the string size_of in rustc's src/ according
to grep and only 3 uses of size_of in servo according to GitHub, so I
think you may be overestimating its usage.
The number of calls to
On 02/02/14 14:18, Daniel Micay wrote:
On Sat, Feb 1, 2014 at 10:12 PM, Eric Reed ecr...@cs.washington.edu wrote:
Well there's only 260 uses of the string size_of in rustc's src/ according
to grep and only 3 uses of size_of in servo according to GitHub, so I
think you may be overestimating its
36 matches
Mail list logo
