On 01/31/2014 09:43 PM, Eric Summers wrote:
I think I like the mut syntax in let expressions, but I still like shoving the
pointer next the type like I would do in C/C++ for something like fn drop(mut
self) {}.
I guess it is somewhat rare to use mutable pointers as function parameters, so
There is not only API change. Sometime, from a minor version to another, a
feature get silently broken (that is silent regression). While it might not
impact libA which depends on it, but it may fail libB which also depends on
it, but with a previous version.
As a result, libA force installation
On 01/02/14 00:09, Tony Arcieri wrote:
On Fri, Jan 31, 2014 at 4:03 PM, Lee Braiden leebr...@gmail.com
mailto:leebr...@gmail.com wrote:
This would be counterproductive. If a library cannot be upgraded
to 1.9, or even 2.2, because some app REQUIRES 1.4, then that
causes SERIOUS,
There are some great points here (that should probably go into some sort of
'best practices' doc for rust package authors).
However there is a fundamental flaw IMO - we are talking about open-source
code, where the author is not obligated to do *any* of this. Most
open-source licenses explicitly
On 01/02/14 00:12, Tony Arcieri wrote:
On Fri, Jan 31, 2014 at 4:07 PM, Vladimir Lushnikov
vladi...@slate-project.org mailto:vladi...@slate-project.org wrote:
Just to be clear, I think what you are saying is that you want
version pinning to be dynamic? I.e. when a new version of a
Portage has a very similar syntax/way of specifying runtime vs. build-time
dependencies: http://devmanual.gentoo.org/general-concepts/dependencies/.
Apt doesn't have support for slots and USE flags (code that is
included/excluded at compile time for optional features).
On Sat, Feb 1, 2014 at
Is it possible at all to find the latest version of a library which is
still compatible completely automatically? Incompatibilites can be
present on logic level, so the compilation wiith incompatible version
will succeed, but the program will work incorrectly. I don't think
that this can be solved
On 01/02/14 09:39, Gaetan wrote:
There is not only API change. Sometime, from a minor version to
another, a feature get silently broken (that is silent regression).
While it might not impact libA which depends on it, but it may fail
libB which also depends on it, but with a previous version.
On 01/02/14 14:55, Vladimir Matveev wrote:
Is it possible at all to find the latest version of a library which is
still compatible completely automatically? Incompatibilites can be
present on logic level, so the compilation wiith incompatible version
will succeed, but the program will work
On 01/02/14 14:49, Vladimir Lushnikov wrote:
Portage has a very similar syntax/way of specifying runtime vs.
build-time dependencies:
http://devmanual.gentoo.org/general-concepts/dependencies/.
Apt doesn't have support for slots and USE flags (code that is
included/excluded at compile time
I think USE flags are more appropriate for library features (which is
exactly the way portage uses them). So you have your rust app with
conditional code that depends on a particular cfg (
https://github.com/mozilla/rust/wiki/Doc-attributes) and then you expose a
list of these in your package
On 01/02/14 15:48, Vladimir Lushnikov wrote:
I think USE flags are more appropriate for library features (which is
exactly the way portage uses them). So you have your rust app with
conditional code that depends on a particular cfg
(https://github.com/mozilla/rust/wiki/Doc-attributes) and then
Ah, this:
On 01/02/14 15:43, Lee Braiden wrote:
extended_begin()
old_funcs()
new_funcs()
extended_end()
should read more like:
begin()
old_funcs()
extended_begin()
new_funcs()
extended_end()
end()
--
Lee
On Fri, Jan 31, 2014 at 1:05 PM, Tony Arcieri basc...@gmail.com wrote:
IMO, a system that respects semantic versioning, allows you to constrain
the dependency to a particular *major* version without requiring pinning
to a *specific* version.
I would call anything that requires pinning to a
why not enforcing in a way or another a API compatibility test suite for
ensuring at least a certain level of compatibility between two version? I
think it is something quite doable, and moreover this would kinda force the
package manager to write unit tests which is always a good practice.
-
On 01/02/14 18:54, Gaetan wrote:
why not enforcing in a way or another a API compatibility test suite
for ensuring at least a certain level of compatibility between two
version? I think it is something quite doable, and moreover this would
kinda force the package manager to write unit tests
On 01/02/14 18:54, Gaetan wrote:
why not enforcing in a way or another a API compatibility test suite
for ensuring at least a certain level of compatibility between two
version? I think it is something quite doable, and moreover this would
kinda force the package manager to write unit tests
You can do that within a major version, except for one case - multiple
developers creating diverged versions of 2.13, based on 2.12, each with
their own features.
...
But doing it per major version recursively raises the question of which
major version is authorised: what if you have a
On 02/01/2014 06:27 AM, Matthieu Monrocq wrote:
In short, isn't there a risk of crashes if one accidentally links two
versions of a given library and start exchanging objects ? It seems
impractical to prove that objects created by one version cannot
accidentally end up being passed to the other
On 01/02/14 19:32, Vladimir Matveev wrote:
When this API is used directly by the package, then the user *should*
know about it. He's using it, after all.
There are developers (direct library users), and then distro
maintainers/admins/users who need to manage libraries installed on their
On 01/02/14 19:59, Isaac Dupree wrote:
On 02/01/2014 06:27 AM, Matthieu Monrocq wrote:
In short, isn't there a risk of crashes if one accidentally links two
versions of a given library and start exchanging objects ? It seems
impractical to prove that objects created by one version cannot
To clarify, when I was writing user I meant the developer who uses this
package, not the end user of complete program.
On 01/02/14 19:32, Vladimir Matveev wrote:
When this API is used directly by the package, then the user *should*
know about it. He's using it, after all.
There are
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).
Hello,
It seems that support for #[link_args] was recently removed (even with
#[feature(link_args)]), so now the -L argument is not being passed to the
linker command:
https://travis-ci.org/cadencemarseille/rust-pcre/builds/18054206
How do you specify a library directory when building a package
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 4:57 AM, Niko Matsakis n...@alum.mit.edu wrote:
Regarding the marker types, they are somewhat awkward, and are not the
approach I originally favored. But they have some real advantages:
- Easily extensible as we add new requirements, unlike syntax.
- Easily documented.
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
We've been steadily reducing the amount of punctuation in the
language, because people tend not to like it. Plus, in this case,
`mut` being longer than `!` or any other symbol is useful: mutability
should be a teeny bit painful.
___
Rust-dev mailing list
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
This might be a recent regression of rustpkg, but rustpkg should pass
through compiler options you give it.
`rustpkg install foo -L some/path` I think is supposed to work.
If nothing else, rustc will definitely take -L arguments. Also, in
your crate source you want to annotate you extern block
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 4:28 PM, Vladimir Matveev
Well, it seems that working for a long time with a code targeting virtual
machines is corrupting :) I completely forgot about different models of
compilation. I see your point. But I think that developing and distributing
should be considered
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
52 matches
Mail list logo
