Rust for C++ Programmers Part 7: Data Types • Hacker News Board

Re: Rust for C++ Programmers Part 7: Data Types

#31

Post by kibwen » Sat, May 24, 2014, 5:13 PM UTC

kzrdude wrote: post #23

kibwen wrote: post #6

Earlier quoted context omitted.

What do you mean by "automatically destructured"? If you mean the extra step of destructuring in the function body, that's not necessary. You can destructure like that anywhere that a pattern is accepted, which includes function parameter lists: struct Foo(int, int); fn bar(Foo(a, b): Foo) { println!("a: {}, b: {}", a, b); } fn main() { let qux = Foo(1, 2); bar(qux); // a: 1, b: 2 }

What they mean is that there would be special cases for let patterns so that let (a, b) = Foo(a,b); is a fine destructuring. It would be a special case for let, since the pattern would have to be more explicit in function arguments and in match, but I think they have a good point.

I should emphasize that tuple structs are a somewhat obscure feature. Their main use case is to support newtyping:

  struct Meters(f64);
  struct Miles(f64);
  let meters = Meters(10.4);
  let miles = metric_to_imperial(meters);
  let Miles(raw_miles) = miles;

The single-arity case above constitutes the vast majority of tuple struct usage. And, as you may expect, in any other context besides tuple structs a single-arity tuple is completely silly (the only reason that we have syntax for single-arity tuples at all is to make writing macros easier).

Ultimately it's just not a feature that would be pulling its weight. If you want a structure with multiple fields where destructuring is not necessary, just use a struct in the first place. Honestly, if we found a better way to support newtyping then I wouldn't be sad if we got rid of tuple structs entirely.

Re: Rust for C++ Programmers Part 7: Data Types

#32

Post by teacup50 » Sat, May 24, 2014, 5:17 PM UTC

pohl wrote: post #30

teacup50 wrote: post #29

Earlier quoted context omitted.

The only failed language experiment are exceptions themselves. I don't use Java APIs that don't throw checked exceptions; if your code does that, I won't even consider working at your place of business, because that means you don't understand that you've written a massive pile of ill-defined failure-prone code. Unchecked exceptions are GOTO on steroids, and those GOTOs are part of the API contract . Java makes except…

I won't even consider working at your place of business... Praise be! The feeling is mutual. I agree to disagree.

Unfortunately, you'll lower the total value of the ecosystem by producing code and advocating practices that lower the level of reliability and correctness of code -- so agreeing to disagree doesn't really solve the issue that you write bad code.

Re: Rust for C++ Programmers Part 7: Data Types

#33

Post by pohl » Sat, May 24, 2014, 5:48 PM UTC

teacup50 wrote: post #32

pohl wrote: post #30

Earlier quoted context omitted.

I won't even consider working at your place of business... Praise be! The feeling is mutual. I agree to disagree.

Unfortunately, you'll lower the total value of the ecosystem by producing code and advocating practices that lower the level of reliability and correctness of code -- so agreeing to disagree doesn't really solve the issue that you write bad code.

So you're saying that it's not possible to write reliable and correct code in a language like C#, and not one C# programmer in the world is worthy of being a colleague to the great teacup50. That's the logical conclusion of your assertions, for all of its exceptions are unchecked, and it is otherwise semantically similar. If it's possible to write reliable and correct code in C#, then it's possible to write reliable and correct code in Java minus checked exceptions.

As far as APIs are concerned, the important thing is that the API is documented to throw something. It's not at all important that the compiler forces you to pollute either the immediate method's body or its signature and the body of the calling method, etc.

Re: Rust for C++ Programmers Part 7: Data Types

#34

Post by teacup50 » Sat, May 24, 2014, 9:20 PM UTC

pohl wrote: post #33

teacup50 wrote: post #32

Earlier quoted context omitted.

Unfortunately, you'll lower the total value of the ecosystem by producing code and advocating practices that lower the level of reliability and correctness of code -- so agreeing to disagree doesn't really solve the issue that you write bad code.

So you're saying that it's not possible to write reliable and correct code in a language like C#, and not one C# programmer in the world is worthy of being a colleague to the great teacup50. That's the logical conclusion of your assertions, for all of its exceptions are unchecked, and it is otherwise semantically similar. If it's possible to write reliable and correct code in C#, then it's possible to write reliable…

No, I'm saying it's not possible to write reliable and correct code in C# using exceptions without also doing all the heavy lifting of the compiler. You can also write reliable and correct code in dynamically typed languages, which involves doing even more work on behalf of the compiler.

This is not unique to C#; if you review coding standards for C++, you'll see plenty of people who have adopted a no-exceptions approach, Google included. Simply put, exceptions are a failed experiment, because checked exceptions are the only mechanism by which the type of your methods is fully defined.

As far as API documentation, that something gets thrown is part of the return signature, and it's no more pollution than expressing the return type is.

Your willingness to employ ambiguity as a means to avoid having to do the work necessary to fully specify your system's behavior is a lazy and logically flawed position; it creates a cognitive load for all consumers of your APIs, and breaks the utility of the compiler that we rely on to write and maintain reliable software more easily.

Re: Rust for C++ Programmers Part 7: Data Types

#35

Post by pohl » Sat, May 24, 2014, 9:39 PM UTC

teacup50 wrote: post #34

pohl wrote: post #33

Earlier quoted context omitted.

So you're saying that it's not possible to write reliable and correct code in a language like C#, and not one C# programmer in the world is worthy of being a colleague to the great teacup50. That's the logical conclusion of your assertions, for all of its exceptions are unchecked, and it is otherwise semantically similar. If it's possible to write reliable and correct code in C#, then it's possible to write reliable…

No, I'm saying it's not possible to write reliable and correct code in C# using exceptions without also doing all the heavy lifting of the compiler. You can also write reliable and correct code in dynamically typed languages, which involves doing even more work on behalf of the compiler. This is not unique to C#; if you review coding standards for C++, you'll see plenty of people who have adopted a no-exceptions appr…

Excuse me, but what exactly is it that you think you know about how I write code?

Re: Rust for C++ Programmers Part 7: Data Types

#36

Post by teacup50 » Sat, May 24, 2014, 9:47 PM UTC

pohl wrote: post #35

teacup50 wrote: post #34

Earlier quoted context omitted.

No, I'm saying it's not possible to write reliable and correct code in C# using exceptions without also doing all the heavy lifting of the compiler. You can also write reliable and correct code in dynamically typed languages, which involves doing even more work on behalf of the compiler. This is not unique to C#; if you review coding standards for C++, you'll see plenty of people who have adopted a no-exceptions appr…

Excuse me, but what exactly is it that you think you know about how I write code?

You rely on human validation of your code's return type values via unchecked exceptions, and don't understand why your code is resultantly ambiguously defined.

Re: Rust for C++ Programmers Part 7: Data Types

#37

Post by pohl » Sat, May 24, 2014, 10:38 PM UTC

teacup50 wrote: post #36

pohl wrote: post #35

Earlier quoted context omitted.

Excuse me, but what exactly is it that you think you know about how I write code?

You rely on human validation of your code's return type values via unchecked exceptions, and don't understand why your code is resultantly ambiguously defined.

LOL...If you're just here to argue against your own imagination I guess you don't need me here.

Re: Rust for C++ Programmers Part 7: Data Types

#38

Post by teacup50 » Sat, May 24, 2014, 10:52 PM UTC

pohl wrote: post #37

teacup50 wrote: post #36

Earlier quoted context omitted.

You rely on human validation of your code's return type values via unchecked exceptions, and don't understand why your code is resultantly ambiguously defined.

LOL...If you're just here to argue against your own imagination I guess you don't need me here.

If you're ignorant to the degree that you don't understand how exceptions are part of the function's return type, it has nothing to do with my imagination.

Re: Rust for C++ Programmers Part 7: Data Types

#39

Post by pohl » Sat, May 24, 2014, 11:09 PM UTC

teacup50 wrote: post #38

pohl wrote: post #37

Earlier quoted context omitted.

LOL...If you're just here to argue against your own imagination I guess you don't need me here.

If you're ignorant to the degree that you don't understand how exceptions are part of the function's return type, it has nothing to do with my imagination.

It's only the imaginary me in your head that doesn't understand that.