3 ms·

1) Sure, pair symbols are a bit rare. But they aren't as rare as you set them to be. Symbols like / | or \ can act as substitute for bracket like syntax. >

by Ygg2 12y ago

1) Sure, pair symbols are a bit rare. But they aren't as rare as you set them to be. Symbols like / | or \ can act as substitute for bracket like syntax. > If we look at languages which did away with this made-up difference we see that pretty much no person is missing it. Eh, not sure what languages are these and how you think they relate to Rust. Keep in mind Rust goal almost from the start was something that is familiar to a people that worked with Gecko engine. With that in mind, I can't think of a similar family language that did this. You know what happens when you call Index/IndexMut. To say it isn't so, is outright fallacious. Also Rust takes the probably best road of allowing limited operator overload, which IMO so far proved better than allowing no operator overload or allowing custom operator overload - which is subject to weird rules and/or leads to heavily overloaded code. Also [] always does same thing. For given Index value it returns value found at that index. & is not an address. AFAIK address are never allowed unless you drop into unsafe. It's a borrow reference to Output value. Index returns immutable version, while IndexMut takes mutable version and returns mutable output value. 2) No we don't. I think having user and built-in defined types is perfectly ok. In any non-Lispy langugage there are special literals, which can't be handled by user defined ways, unless you allow for some funky grammar. 4) Related yes, same no. In same way i32 and u32 are related but not the same. As I said in previous question having some subset of language be unable to modify is IMHO a good thing. 6/7) They can't. You can tell by mutability of array which one will be called and which one will be returned. You CAN'T EVER change type of mutability of result. 9) Whenever I see macros/operator overload/syntax being given too much freedom, it always ends up with incomprehensible DSL-s that you can't disentangle from regular code. 10) Subjective opinion. And it could be trivially solved with better type aliases. 12) I don't think it's a big problem and a fix to Cargo that adds a special unique identifier should be trivial to implement, although not necessarily forward/backward compatible.

Ygg2 12y ago
What multiple Rust proponents? Where? What people consider [] superior to <>? How many? Your text have an air of superiority but your arguments leave a lot to be desired or to be more frank [Citation needed].
frowaway001 12y ago
1) \ is usually taken for escapes, | is non-directional and therefore doesn't work with arbitrary nesting, and / causes the same problems as <. > Keep in mind Rust goal almost from the start was > something that is familiar to a people that worked > with Gecko engine. With that in mind, I can't think > of a similar family language that did this. Isn't this the classic Golang emergency excuse? "Golang was built by Google engineers to solve Google's problems, so could you please kindly **** off, dear non-Googler." Nobody claims that <> isn't "familiar". People are claiming that <> isn't very good, and they are correct with that. Those languages which made <> "familiar" picked <> because they added templates/generics/... after the fact and tried to bolt them onto an existing language without breaking all existing code. <> was usually the least worst option for those languages. It doesn't follow that a language designed from scratch should adopt <> without thinking, because there are better alternatives when designing a language which has Generics from day 1. > You know what happens when you call Index/IndexMut. > To say it isn't so, is outright fallacious. extern crate rand; use std::ops::{Index,IndexMut}; use rand::random; fn main() { let mut arr = MyFunnyArray { arr: [0,1,2] }; println!("arr is {:?}", arr); arr[5] = 23; println!("arr is {:?}", arr); } #[derive(Debug)] struct MyFunnyArray { arr: [u32; 3] } impl Index<usize> for MyFunnyArray { type Output = u32; fn index<'a>(&self, _index: usize) -> &u32 { &self.arr[random::<usize>() % 3] } } impl IndexMut<usize> for MyFunnyArray { fn index_mut<'a>(&'a mut self, _index: usize) -> &'a mut u32 { self.arr[random::<usize>() % 3] = random(); &mut self.arr[random::<usize>() % 3] } } Looks pretty arbitrary to me. 2) > No we don't. I think having user and built-in > defined types is perfectly ok. Sure, but how is this even related to the topic? 4) > Related yes, same no. In same way i32 and u32 are > related but not the same. As you might see, they are called i32 and u32, not i32 and UnsignedInt4Bytes. > As I said in previous question having some subset of > language be unable to modify is IMHO a good thing. I'm not sure what you are trying to argue here. Consistency has nothing to do with being "able/unable to modify". People are unable to modify most types, it doesn't matter if they come from a third-party crate or the core language. 6/7) > They can't. You can tell by mutability of array which > one will be called and which one will be returned. > You CAN'T EVER change type of mutability of result. Not sure what you suddenly try so say with "you can't modify this", "you can't mutate that". As shown in 1) [] can do whatever the developer implements. Sure, the usual language rules apply, I think nobody disagreed on that. 9) > Whenever I see macros/operator overload/syntax being > given too much freedom, it always ends up with > incomprehensible DSL-s that you can't disentangle from > regular code. Yes, that's exactly the concern I'm raising here, because that's what Rust is encouraging. 10) No, not really. Just compare the issues caused by using <> vs. other approaches.
Ygg2 12y ago
> Nobody claims that <> isn't "familiar". People are claiming > that <> isn't very good, and they are correct with that. > Those languages which made <> "familiar" picked <> because > they added templates/generics/... after the fact and tried > to bolt them onto an existing language without breaking all > existing code. What people are claiming this? Is there some argument <Type, <Type<Type>>> is much better than [Type, [Type[Type]]] in monospaced fonts? I agree I prefer it, but I know it comes down to subjectivity and familiarity. Not the most compelling reasons. > impl Index<usize> for MyFunnyArray { type Output = u32; fn index<'a>(&self, _index: usize) -> &u32 { &self.arr[random::<usize>() % 3] } } impl IndexMut<usize> for MyFunnyArray { fn index_mut<'a>(&'a mut self, _index: usize) -> &'a mut u32 { self.arr[random::<usize>() % 3] = random(); &mut self.arr[random::<usize>() % 3] } } Sure, you can write that, but you can also write: fn getIndex(&self, index: usize) { self.arr[random::<usize>()%self.arr.length] } Rust won't protect you from stupid mistakes. The only question is whether it will allow you to override index syntax. myArray[3] myArray.getIndex(3) I actually prefer this small token of power, as opposed to having to write: date1.compareTo(date2) < 0 date1.equalsTo(date2) date1.index(at) That gets tedious fast. > As you might see, they are called i32 and u32, not i32 and UnsignedInt4Bytes. Correct, because they are both built in literals. String isn't a built in literal. You can't have: u32::new() >Not sure what you suddenly try so say with "you can't >modify this", "you can't mutate that". >As shown in 1) [] can do whatever the developer implements. >Sure, the usual language rules apply, I think nobody >disagreed on that. No matter how many time you call Index on your array it stays the same. What kind of trippy Index you want to implement is still there, only with uglier syntax. > Yes, that's exactly the concern I'm raising here, because that's what Rust is encouraging. It's not. All macro invocations are fenced in by macro calls. All syntax extensions are followed by extension calls. Could macros/syntax extensions do horrible things? Sure. So can regular code.
frowaway001 12y ago
Not sure if further replies make sense. You seem to have either some issues understanding the text or acting dense on purpose, opting to argue against points which were never suggested. Considering that multiple Rust proponents tried very hard to argue against the issues I raised, but failed to make any convincing point in their favor, I leave this debate with a positive attitude and strengthened facts. Thanks.

by Ygg2 12y ago

Ygg2 12y ago

What multiple Rust proponents? Where? What people consider [] superior to <>? How many? Your text have an air of superiority but your arguments leave a lot to be desired or to be more frank [Citation needed].

frowaway001 12y ago

1) \ is usually taken for escapes, | is non-directional and therefore doesn't work with arbitrary nesting, and / causes the same problems as <. > Keep in mind Rust goal almost from the start was > something that is familiar to a people that worked > with Gecko engine. With that in mind, I can't think > of a similar family language that did this. Isn't this the classic Golang emergency excuse? "Golang was built by Google engineers to solve Google's problems, so could you please kindly **** off, dear non-Googler." Nobody claims that <> isn't "familiar". People are claiming that <> isn't very good, and they are correct with that. Those languages which made <> "familiar" picked <> because they added templates/generics/... after the fact and tried to bolt them onto an existing language without breaking all existing code. <> was usually the least worst option for those languages. It doesn't follow that a language designed from scratch should adopt <> without thinking, because there are better alternatives when designing a language which has Generics from day 1. > You know what happens when you call Index/IndexMut. > To say it isn't so, is outright fallacious. extern crate rand; use std::ops::{Index,IndexMut}; use rand::random; fn main() { let mut arr = MyFunnyArray { arr: [0,1,2] }; println!("arr is {:?}", arr); arr[5] = 23; println!("arr is {:?}", arr); } #[derive(Debug)] struct MyFunnyArray { arr: [u32; 3] } impl Index<usize> for MyFunnyArray { type Output = u32; fn index<'a>(&self, _index: usize) -> &u32 { &self.arr[random::<usize>() % 3] } } impl IndexMut<usize> for MyFunnyArray { fn index_mut<'a>(&'a mut self, _index: usize) -> &'a mut u32 { self.arr[random::<usize>() % 3] = random(); &mut self.arr[random::<usize>() % 3] } } Looks pretty arbitrary to me. 2) > No we don't. I think having user and built-in > defined types is perfectly ok. Sure, but how is this even related to the topic? 4) > Related yes, same no. In same way i32 and u32 are > related but not the same. As you might see, they are called i32 and u32, not i32 and UnsignedInt4Bytes. > As I said in previous question having some subset of > language be unable to modify is IMHO a good thing. I'm not sure what you are trying to argue here. Consistency has nothing to do with being "able/unable to modify". People are unable to modify most types, it doesn't matter if they come from a third-party crate or the core language. 6/7) > They can't. You can tell by mutability of array which > one will be called and which one will be returned. > You CAN'T EVER change type of mutability of result. Not sure what you suddenly try so say with "you can't modify this", "you can't mutate that". As shown in 1) [] can do whatever the developer implements. Sure, the usual language rules apply, I think nobody disagreed on that. 9) > Whenever I see macros/operator overload/syntax being > given too much freedom, it always ends up with > incomprehensible DSL-s that you can't disentangle from > regular code. Yes, that's exactly the concern I'm raising here, because that's what Rust is encouraging. 10) No, not really. Just compare the issues caused by using <> vs. other approaches.

Ygg2 12y ago

> Nobody claims that <> isn't "familiar". People are claiming > that <> isn't very good, and they are correct with that. > Those languages which made <> "familiar" picked <> because > they added templates/generics/... after the fact and tried > to bolt them onto an existing language without breaking all > existing code. What people are claiming this? Is there some argument <Type, <Type<Type>>> is much better than [Type, [Type[Type]]] in monospaced fonts? I agree I prefer it, but I know it comes down to subjectivity and familiarity. Not the most compelling reasons. > impl Index<usize> for MyFunnyArray { type Output = u32; fn index<'a>(&self, _index: usize) -> &u32 { &self.arr[random::<usize>() % 3] } } impl IndexMut<usize> for MyFunnyArray { fn index_mut<'a>(&'a mut self, _index: usize) -> &'a mut u32 { self.arr[random::<usize>() % 3] = random(); &mut self.arr[random::<usize>() % 3] } } Sure, you can write that, but you can also write: fn getIndex(&self, index: usize) { self.arr[random::<usize>()%self.arr.length] } Rust won't protect you from stupid mistakes. The only question is whether it will allow you to override index syntax. myArray[3] myArray.getIndex(3) I actually prefer this small token of power, as opposed to having to write: date1.compareTo(date2) < 0 date1.equalsTo(date2) date1.index(at) That gets tedious fast. > As you might see, they are called i32 and u32, not i32 and UnsignedInt4Bytes. Correct, because they are both built in literals. String isn't a built in literal. You can't have: u32::new() >Not sure what you suddenly try so say with "you can't >modify this", "you can't mutate that". >As shown in 1) [] can do whatever the developer implements. >Sure, the usual language rules apply, I think nobody >disagreed on that. No matter how many time you call Index on your array it stays the same. What kind of trippy Index you want to implement is still there, only with uglier syntax. > Yes, that's exactly the concern I'm raising here, because that's what Rust is encouraging. It's not. All macro invocations are fenced in by macro calls. All syntax extensions are followed by extension calls. Could macros/syntax extensions do horrible things? Sure. So can regular code.

frowaway001 12y ago

Not sure if further replies make sense. You seem to have either some issues understanding the text or acting dense on purpose, opting to argue against points which were never suggested. Considering that multiple Rust proponents tried very hard to argue against the issues I raised, but failed to make any convincing point in their favor, I leave this debate with a positive attitude and strengthened facts. Thanks.