Re: [rust-dev] Virtual fn is a bad idea
I thought that the RFC for a virtual fn alternative pushed a couple days ago by Bill Myers looked interesting: https://github.com/bill-myers/rfcs/blob/5e62f881421fc6aa34e85ffc5b2a91a7d370/active/-oop-with-enums.md I can’t tell if it is elegant or an evil contortion of existing Rust features though. I’m curious what people think of it since it is much different then the other proposals out there. Eric On Mar 17, 2014, at 3:19 PM, Jan Klesnil kles...@centrum.cz wrote: Hi, I've just read your proposal. It is pretty similar to an idea I had over the weekend. However, there is one thing I want to ask about. But I will present my idea because it may be the case that I misunderstood some part from your proposal. My idea was to introduce few orthogonal concepts and use them together to solve the DOM problem: 1) single static inheritance and static cast to base types 2) virtual struct WITHOUT any virtual methods 3) dynamic cast to derived type or implemented trait for virtual structs Structs that are declared virtual will have a hidden pointer to some vtable-like structure that allows dynamic casting to derived types and to traits. So the layout is similar to C++'s virtual classes, but there are no virtual methods. Instead, you would be able to cast to any implemented trait dynamically. If I understand your proposal correctly, it is the same as the FatT as U relation. I see that this FatT as U relation is absolutely doable, but I was not able to come up with any efficient solution and I see performance of the dynamic cast as very important property. Otherwise the feature will be very useful. My baseline solution was to build hashtable for every crate with key of pair (T,U) and search the hashtables when the dynamic cast is requested. That was just a proof that it is doable because it is not efficient solution. I also expect that some v-table structure can be generated for each virtual struct as far as we know all the implemented traits. (E.g., at link time for entire crate.) But when I considered implementing traits for virtual struct from different crate, it became more difficult and I stopped examining the problem. So my questions would be: Did I understood the meaning of the Fat relation correctly? Is the Fat relation already implemented? Or is there a proposal for the implementation somewhere? J On 03/15/2014 05:30 AM, Micah Chalmer wrote: I wrote up an alternative proposal that I think, if I’m understanding them correctly, meets all the requirements. I submitted it as an RFC, so discussion of it is probably better put on github on the mailing list, but in case anyone interested is watching this thread and not watching the RFCs: https://github.com/rust-lang/rfcs/pull/9 -Micah ___ 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 mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Virtual fn is a bad idea
Matthieu,
I tried to model something similar this way. Sometimes the extra pattern
matching gets tedious with this approach. You also end up with a lot of
constructors with similar names. I also found myself writing a lot of trivial
function wrappers around constructors. Of course there are benefits to a
non-extensible system like this. For instance, you can tell if you have
addressed every case in a match statement.
Someone on IRC mentioned that a feature similar to Haskell pattern synonyms may
make it less awkward to use these enum wrappers.
Eric
On Mar 13, 2014, at 12:56 PM, Matthieu Monrocq matthieu.monr...@gmail.com
wrote:
And of course I forgot to reply to the list at large... sorry :x
-- Matthieu
On Wed, Mar 12, 2014 at 8:48 PM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
On Tue, Mar 11, 2014 at 10:18 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 3/11/14 2:15 PM, Maciej Piechotka wrote:
Could you elaborate on DOM? I saw it referred a few times but I haven't
seen any details. I wrote simple bindings to libxml2 dom
(https://github.com/uzytkownik/xml-rs - warning - I wrote it while I was
learning ruby) and I don't think there was a problem of OO - main
problem was mapping libxml memory management and rust's one [I gave up
with namespaces but with native rust dom implementation it would be
possible to solve in nicer way]. Of course - I might've been at too
early stage.
You need:
1. One-word pointers to each DOM node, not two. Every DOM node has 5 pointers
inside (parent, first child, last child, next sibling, previous sibling).
Using trait objects would 10 words, not 5 words, and would constitute a large
memory regression over current browser engines.
2. Access to fields common to every instance of a trait without virtual
dispatch. Otherwise the browser will be at a significant performance
disadvantage relative to other engines.
3. Downcasting and upcasting.
4. Inheritance with the prefix property, to allow for (2).
If anyone has alternative proposals that handle these constraints that are
more orthogonal and are pleasant to use, then I'm happy to hear them. I'm
just saying that dismissing the feature out of hand is not productive.
Patrick
Please excuse me, I need some kind of visualization here, so I concocted a
simple tree:
// So, in pseudo C++, let's imagine a DOM tree
struct Element { Element *parent, *prevSib, *nextSib, *firstChild,
*lastChild; uint leftPos, topPos, height, width; bool hidden; };
struct Block: Element { BlockProperties blockP; }; struct Div: Block {};
struct Inline: Element { InlineProperties inlineP; }; struct Span: Inline {};
Now, I'll be basically mimicking the way LLVM structures its AST, since the
LLVM AST achieves dynamic casting without RTTI. Note that this has a very
specific downside: the hierarchy is NOT extensible.
// And now in Rust (excuse my poor syntax/errors)
enum ElementChild'r { ChildBlock('r Block), ChildInline('r Inline) }
struct Element {
child: Option'self ElementChild'self;
parent: 'self Element;
prevSib, nextSib, firstChild, lastChild: Option'self Element;
leftPos, topPos, height, width: uint;
hidden: bool;
}
enum BlockChild'r { ChildDiv('r Div) }
struct Block {
elementBase: Element;
child: Option'self BlockChild'self;
blockP: BlockProperties;
}
struct Div { blockBase: Block; }
enum InlineChild'r { ChildSpan('r Span) }
struct Inline {
elementBase: Element;
child: Option'self InlineChild'self;
inlineP: InlineProperties;
}
struct Span { inlineBase: Inline; }
Let us review our objectives:
(1) One word to each DOM element: check = Option'r Element
(2) Direct access to a field, without indirection: check =
span.inlineBase.elementBase.hidden
(3) Downcast and upcasting: check = downcast is done by matching:
match(element.child) { ChildBlock('r block) = /* act on block */,
ChildInline('r inline) = /* act on inline */); upcast is just accessing the
base field.
(4) Inheritance with the prefix property = not necessary, (2) is already
satisfied.
Note on (3): multiple bases are allowed easily, it's one field per base.
In order to reduce the foot-print; avoiding having a child field at each
level of the hierarchy might be beneficial. In this case, only the final
classes are considered in ElementChild
enum ElementChild'r { ChildDiv('r Div), ChildSpan('r Span) }
And then downcasting to 'r Block is achieved by:
match(element.final) { ChildDiv('r div) = Some('r div.blockBase), _ =
None }
I would note that this does not make use of traits at all; the analysis is
only based on Patrick's list of objectives which I guess is incomplete and I
was lacking a realistic example so it might not address the full scope of the
problem...
... still, for CLOSED hierarchies, the use of traits should not be necessary,
Re: [rust-dev] Virtual fn is a bad idea
Also this approach uses more memory. At least a byte per pointer and maybe
more with padding. In most cases like this you would prefer to use a vtable
instead of tags to reduce the memory footprint.
Eric
On Mar 13, 2014, at 1:17 PM, Eric Summers eric.summ...@me.com wrote:
Matthieu,
I tried to model something similar this way. Sometimes the extra pattern
matching gets tedious with this approach. You also end up with a lot of
constructors with similar names. I also found myself writing a lot of
trivial function wrappers around constructors. Of course there are benefits
to a non-extensible system like this. For instance, you can tell if you have
addressed every case in a match statement.
Someone on IRC mentioned that a feature similar to Haskell pattern synonyms
may make it less awkward to use these enum wrappers.
Eric
On Mar 13, 2014, at 12:56 PM, Matthieu Monrocq matthieu.monr...@gmail.com
wrote:
And of course I forgot to reply to the list at large... sorry :x
-- Matthieu
On Wed, Mar 12, 2014 at 8:48 PM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
On Tue, Mar 11, 2014 at 10:18 PM, Patrick Walton pcwal...@mozilla.com
wrote:
On 3/11/14 2:15 PM, Maciej Piechotka wrote:
Could you elaborate on DOM? I saw it referred a few times but I haven't
seen any details. I wrote simple bindings to libxml2 dom
(https://github.com/uzytkownik/xml-rs - warning - I wrote it while I was
learning ruby) and I don't think there was a problem of OO - main
problem was mapping libxml memory management and rust's one [I gave up
with namespaces but with native rust dom implementation it would be
possible to solve in nicer way]. Of course - I might've been at too
early stage.
You need:
1. One-word pointers to each DOM node, not two. Every DOM node has 5
pointers inside (parent, first child, last child, next sibling, previous
sibling). Using trait objects would 10 words, not 5 words, and would
constitute a large memory regression over current browser engines.
2. Access to fields common to every instance of a trait without virtual
dispatch. Otherwise the browser will be at a significant performance
disadvantage relative to other engines.
3. Downcasting and upcasting.
4. Inheritance with the prefix property, to allow for (2).
If anyone has alternative proposals that handle these constraints that are
more orthogonal and are pleasant to use, then I'm happy to hear them. I'm
just saying that dismissing the feature out of hand is not productive.
Patrick
Please excuse me, I need some kind of visualization here, so I concocted a
simple tree:
// So, in pseudo C++, let's imagine a DOM tree
struct Element { Element *parent, *prevSib, *nextSib, *firstChild,
*lastChild; uint leftPos, topPos, height, width; bool hidden; };
struct Block: Element { BlockProperties blockP; }; struct Div: Block {};
struct Inline: Element { InlineProperties inlineP; }; struct Span: Inline {};
Now, I'll be basically mimicking the way LLVM structures its AST, since the
LLVM AST achieves dynamic casting without RTTI. Note that this has a very
specific downside: the hierarchy is NOT extensible.
// And now in Rust (excuse my poor syntax/errors)
enum ElementChild'r { ChildBlock('r Block), ChildInline('r Inline) }
struct Element {
child: Option'self ElementChild'self;
parent: 'self Element;
prevSib, nextSib, firstChild, lastChild: Option'self Element;
leftPos, topPos, height, width: uint;
hidden: bool;
}
enum BlockChild'r { ChildDiv('r Div) }
struct Block {
elementBase: Element;
child: Option'self BlockChild'self;
blockP: BlockProperties;
}
struct Div { blockBase: Block; }
enum InlineChild'r { ChildSpan('r Span) }
struct Inline {
elementBase: Element;
child: Option'self InlineChild'self;
inlineP: InlineProperties;
}
struct Span { inlineBase: Inline; }
Let us review our objectives:
(1) One word to each DOM element: check = Option'r Element
(2) Direct access to a field, without indirection: check =
span.inlineBase.elementBase.hidden
(3) Downcast and upcasting: check = downcast is done by matching:
match(element.child) { ChildBlock('r block) = /* act on block */,
ChildInline('r inline) = /* act on inline */); upcast is just accessing
the base field.
(4) Inheritance with the prefix property = not necessary, (2) is already
satisfied.
Note on (3): multiple bases are allowed easily, it's one field per base.
In order to reduce the foot-print; avoiding having a child field at each
level of the hierarchy might be beneficial. In this case, only the final
classes are considered in ElementChild
enum ElementChild'r { ChildDiv('r Div), ChildSpan('r Span) }
And then downcasting to 'r Block is achieved by:
match(element.final) { ChildDiv('r div) = Some('r div.blockBase), _ =
None }
I would note that this does not make
Re: [rust-dev] Virtual fn is a bad idea
Yes, but with tags you pay the cost even if Option is None. Eric On Mar 13, 2014, at 1:33 PM, Daniel Micay danielmi...@gmail.com wrote: On 13/03/14 02:25 PM, Eric Summers wrote: Also this approach uses more memory. At least a byte per pointer and maybe more with padding. In most cases like this you would prefer to use a vtable instead of tags to reduce the memory footprint. Eric A vtable uses memory too. Either it uses a fat pointer or adds at least one pointer to the object. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Virtual fn is a bad idea
A really out there solution to reduce memory may be to use a Cap’n Proto style arena that uses offsets instead of pointers, but I’m sure there are a lot of difficult problems with that. Eric On Mar 13, 2014, at 1:37 PM, Eric Summers eric.summ...@me.com wrote: Yes, but with tags you pay the cost even if Option is None. Eric On Mar 13, 2014, at 1:33 PM, Daniel Micay danielmi...@gmail.com wrote: On 13/03/14 02:25 PM, Eric Summers wrote: Also this approach uses more memory. At least a byte per pointer and maybe more with padding. In most cases like this you would prefer to use a vtable instead of tags to reduce the memory footprint. Eric A vtable uses memory too. Either it uses a fat pointer or adds at least one pointer to the object. ___ 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
Re: [rust-dev] Virtual fn is a bad idea
Thinking about this a bit more, maybe the memory cost could go away with tagged pointers. That is easier to do on a 64-bit platform though. Eric On Mar 13, 2014, at 1:37 PM, Eric Summers eric.summ...@me.com wrote: Yes, but with tags you pay the cost even if Option is None. Eric On Mar 13, 2014, at 1:33 PM, Daniel Micay danielmi...@gmail.com wrote: On 13/03/14 02:25 PM, Eric Summers wrote: Also this approach uses more memory. At least a byte per pointer and maybe more with padding. In most cases like this you would prefer to use a vtable instead of tags to reduce the memory footprint. Eric A vtable uses memory too. Either it uses a fat pointer or adds at least one pointer to the object. ___ 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
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
I don’t like the glob patterns either, but I might like them more if a module
could define a “prelude” and only those symbols would be imported by a glob
pattern. For example, if you say `use std::str::*`, you would automatically
get the functions but not rarely used things like the raw module.
Maybe just a corruption of existing syntax like:
mymod.rs
```
mod * {
pub use { MyStruct, my_func, MyEnum };
}
pub struct MyStruct {
[…]
}
[…]
```
Eric
On Mar 12, 2014, at 1:57 PM, Daniel Micay danielmi...@gmail.com wrote:
On 12/03/14 06:38 AM, Huon Wilson wrote:
Certain aspects of them dramatically complicate the name resolution
algorithm (as I understand it), and, anyway, they have various downsides
for the actual code, e.g. the equivalent in Python is frowned upon:
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing
Maybe they aren't so bad in a compiled statically typed language? I
don't know; either way, I personally find code without glob imports
easier to read, because I can work out which function is being called
very easily, whereas glob imports require more effort.
Huon
I think it's still pretty bad. It makes it *very* hard to read the code
because it's not clear where the names are coming from.
___
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
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
I think it helps that Rust allows imports in any block. You could use glob
imports like this with little risk of breaking:
```
fn foo() {
import std::str::*
[..]
}
```
Eric
On Mar 12, 2014, at 2:17 PM, Bob Ippolito b...@redivi.com wrote:
Glob imports work well up front but aren't good for maintenance. In Haskell
if a popular library adds a new function it could easily break any packages
that depend on it that use glob imports. It's more work but almost always
best to explicitly import individual names. A tool could help with this
though.
On Wednesday, March 12, 2014, Huon Wilson dbau...@gmail.com wrote:
Certain aspects of them dramatically complicate the name resolution algorithm
(as I understand it), and, anyway, they have various downsides for the actual
code, e.g. the equivalent in Python is frowned upon:
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing
Maybe they aren't so bad in a compiled statically typed language? I don't
know; either way, I personally find code without glob imports easier to read,
because I can work out which function is being called very easily, whereas
glob imports require more effort.
Huon
On 12/03/14 20:44, Liigo Zhuang wrote:
glob use just make compiler loading more types, but make programmers a lot
easy (to write, to remember). perhaps I'm wrong? thank you!
--
by Liigo, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/
___
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 mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
Fixed ;-)
On Mar 12, 2014, at 2:19 PM, Eric Summers eric.summ...@me.com wrote:
I think it helps that Rust allows imports in any block. You could use glob
imports like this with less risk of breaking:
```
fn foo() {
use std::str::*
[..]
}
```
Eric
On Mar 12, 2014, at 2:17 PM, Bob Ippolito b...@redivi.com wrote:
Glob imports work well up front but aren't good for maintenance. In Haskell
if a popular library adds a new function it could easily break any packages
that depend on it that use glob imports. It's more work but almost always
best to explicitly import individual names. A tool could help with this
though.
On Wednesday, March 12, 2014, Huon Wilson dbau...@gmail.com wrote:
Certain aspects of them dramatically complicate the name resolution
algorithm (as I understand it), and, anyway, they have various downsides for
the actual code, e.g. the equivalent in Python is frowned upon:
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing
Maybe they aren't so bad in a compiled statically typed language? I don't
know; either way, I personally find code without glob imports easier to
read, because I can work out which function is being called very easily,
whereas glob imports require more effort.
Huon
On 12/03/14 20:44, Liigo Zhuang wrote:
glob use just make compiler loading more types, but make programmers a
lot easy (to write, to remember). perhaps I'm wrong? thank you!
--
by Liigo, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/
___
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 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
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
Yes, but you can minimize the risk. Particularly if you are importing your own
modules. Just need to use some common sense.
If you are referring to importing at the block level, I see a lot of Rust code
doing that including in the compiler. Glob imports are not really used though.
Like most people, I’m not sure how I feel about them yet.
Eric
On Mar 12, 2014, at 2:45 PM, Bob Ippolito b...@redivi.com wrote:
Is that what people actually do? You still risk breakage if you glob import
from two or more modules in the same block.
On Wed, Mar 12, 2014 at 12:22 PM, Eric Summers eric.summ...@me.com wrote:
Fixed ;-)
On Mar 12, 2014, at 2:19 PM, Eric Summers eric.summ...@me.com wrote:
I think it helps that Rust allows imports in any block. You could use glob
imports like this with less risk of breaking:
```
fn foo() {
use std::str::*
[..]
}
```
Eric
On Mar 12, 2014, at 2:17 PM, Bob Ippolito b...@redivi.com wrote:
Glob imports work well up front but aren't good for maintenance. In Haskell
if a popular library adds a new function it could easily break any packages
that depend on it that use glob imports. It's more work but almost always
best to explicitly import individual names. A tool could help with this
though.
On Wednesday, March 12, 2014, Huon Wilson dbau...@gmail.com wrote:
Certain aspects of them dramatically complicate the name resolution
algorithm (as I understand it), and, anyway, they have various downsides
for the actual code, e.g. the equivalent in Python is frowned upon:
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing
Maybe they aren't so bad in a compiled statically typed language? I don't
know; either way, I personally find code without glob imports easier to
read, because I can work out which function is being called very easily,
whereas glob imports require more effort.
Huon
On 12/03/14 20:44, Liigo Zhuang wrote:
glob use just make compiler loading more types, but make programmers a
lot easy (to write, to remember). perhaps I'm wrong? thank you!
--
by Liigo, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/
___
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 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
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
Maybe I’m wrong, but I’m not sure this is accurate. rustdoc does all of this with libsyntax including jumping to the line of the actual source code for a symbol. Maybe it isn’t perfectly ideal for some tools, but I don’t think it is anywhere near a lost cause. Eric On Mar 12, 2014, at 2:52 PM, Clark Gaebel cgae...@uwaterloo.ca wrote: There is no accurate jump-to-definition, type retrieval, docstring retrieval or semantic completion for Rust. The compiler was not built with support for this kind of tooling in mind, and I seriously doubt that anything but inaccurate hacks will exist for a *long* time. This worries me a lot. -- Clark. Key ID : 0x78099922 Fingerprint: B292 493C 51AE F3AB D016 DD04 E5E3 C36F 5534 F907 ___ 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
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
That makes sense. Rust is an easier language to parse then C/C++ though, so maybe it isn’t necessary. Just need to convert the source in to an AST with an alternate parser that can throw out stuff that is invalid. Then analyze it with the compiler. Eric On Mar 12, 2014, at 3:07 PM, Daniel Micay danielmi...@gmail.com wrote: On 12/03/14 03:52 PM, Clark Gaebel wrote: There is no accurate jump-to-definition, type retrieval, docstring retrieval or semantic completion for Rust. The compiler was not built with support for this kind of tooling in mind, and I seriously doubt that anything but inaccurate hacks will exist for a *long* time. This worries me a lot. It would need to be able to perform type checking/inference even if the file can't be fully parsed, or there are type errors in other places. At the moment, each phase simply assumes all of the previous stages were fully completed, and it bails out immediately on any error by unwinding via failure. It's easy to see this from the error reporting. Rust can report multiple errors within the same phase, but it's unable to report a type error if parsing fails. `clang` was designed with this kind of thing as a central pillar and is able to continue reporting errors or giving useful results to queries from tooling even if there are problems. It's not at all an easy task, and most compilers are not able to do it. A language like Go is simple enough that tooling like completion can be done without help from a compiler. However, Rust has powerful local type inference, which presents a difficult obstacle. Another enormous obstacle is the power of traits - a type can have methods provided by traits, if the trait is in scope and the type is covered by an implementation, which may be generic. ___ 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
Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax
```
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? Essentially allow the for all to be shared. While I’ve
been skimming code to learn Rust, I noticed trait restrictions in particular
seem to be repeated a lot in functions and traits that are related to each
other.
forallT:ByteStream, U {
impl BinaryEncoderT for MyStructU { … }
impl BinaryDecoderT for MyStructU { … }
}
I also like how it breaks across lines:
forallT, U
struct Foo {
...
}
It looks like someone else suggested this while I was typing, but I like the
aesthetics of it.
-Eric
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax
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
struct Foo {
…
}
I guess it currently breaks ok for long type params:
implT, U
TraitT
for FooT,U {
...
}
I think the grep issue will be solved by libsyntax being integrated in text
editor plugins.
-Eric
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] let mut - let !
I’m new to Rust (three days), but I thought the mut syntax felt odd in a few
places. Type definitions in particular because it is one of the few places
that require padding. Is there any reason a symbol isn’t used for mutability
instead? Forgive me if I’m too naive in Rust.
With a symbol you can drop the space:
fn drop(mut self) { .. } - fn drop(!self)
The only other common situation I've seen so for that require the space are
lifetime annotations. Maybe there is an alternate form for those?
The symbol could probably be extended to let:
let mut a = 0; - let !a = 0; - let a: !u32 = 0;
or maybe mutable setter;
let a := 0;
As other said, I think ‘var' sugar feels against the design of the language.
-Eric
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] let mut - let !
let !a = 0 is ambiguous with macros. (cf. `let! a = 0;`) Patrick The symbol was hypothetical. Maybe a different symbol or maybe only in types. The let mut syntax didn’t look as strange to me. The extra spaces in types felt a little more difficult to parse in my head while skimming code, but I’m sure I would get used to that. -Eric ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] let mut - let !
I realized my example didn’t make sense for pattern matching.
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
maybe not a big deal.
Sorry for extending the thread.
-Eric
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
