I just noticed I missed assembly-line. I’ll add that in later.
I’m having trouble understanding your meaning here.
The difference between Rust’s structs and ‘objects’ in other languages is that the latter ‘physically’ carry (in memory or through some sort of resolution at runtime) references to methods, whereas Rust’s structs don’t. Consequently, the semantic (might not be exactly the right word) differences between ‘functions’ and ‘methods’ that exist in those other languages do not exist in Rust.
Methods in Rust are just associated functions (book, reference) that are annotated with self as their first argument. (Rust Playground)
I suspect the dot syntax was chosen to be reminiscent of the object member access syntax from other languages. It is syntactic sugar for :: – see the reference.
Rust’s official linter, clippy, will complain if explicit returns are used where implicit ones are possible. I want to push our students to use clippy, so I’m strongly in favor of implicit returns.
cars-assemble
I need to be taught (adding to Jeremy, @MatthijsBlom pointed these out already):
- comparison operators
==,<,<=etc. - type casting with
as
This is another one of those PRs where the task is almost identical as assembly-line. What’s up with that? Are we going to merge these two?
The rest of Jeremy’s analysis I agree with.
I mean that if you look in the source code, so will float be defined in a struct.
Rust is a bit weird about object-oriented programming in my personal opinion, meaning it doesn’t really act like other object-oriented languages.
As far as I understand so is the major difference between a function and a method, is that functions can only work with the provided data while methods can access all the data provided in the given instance. But as a grand rule, all “functions” defined inside a struct, enum or trait is a method and everything else is a function.
What source code? f64 is a compiler built-in primitive type. Why would it be defined inside a struct?
the major difference between a function and a method, is that functions can only work with the provided data while methods can access all the data provided in the given instance.
I don’t understand. In Rust, every function or method can only access what has been passed into it explicitly. The “method receiver” is just another argument and not treated in a special way.
But as a grand rule, all “functions” defined inside a struct, enum or trait is a method and everything else is a function.
Not really… While OOP languages often define methods right inside the class definition (literally inside the same curly braces), Rust doesn’t do that. Rust’s methods and associated functions are defined in impl blocks, which can be located anywhere. You can even add methods and associated functions to foreign types, ones from the standard library or third party crates, although you need to define a trait for that. Also, you can define “associated functions” in such blocks which do not take a method receiver (self). They are not called methods.
What source code?
f64is a compiler built-in primitive type. Why would it be defined inside a struct?
Other languages use a struct to define data types. But my bad, it was a pure guess, I had personally never seen the definition.
Don’t mean littarly inside.
In oop languages you can also deffine methods outside of a class:
module Methods
def something
"ab"
end
end
class Something
include Methods
end
(You can also define a method outside of a module or class but then it becomes a class method (which is more or less a function but since in ruby everything is an object so is it a method) and not an instance method).
But also it makes sense that “functions” that don’t take self as a parameter is a function and I meant as a general rule, there are of course expectations.
I don’t understand. In Rust, every function or method can only access what has been passed into it explicitly. The “method receiver” is just another argument and not treated in a special way.
I mean that take for example python:
class Something:
def __init__(self, abc):
self.abc = abc
def something(self, abc):
self.abc = abc
(I know I deserve awards for my very good variable names)
We see here also self, since python can also only access what has been passed explicitly (it can although deal with global variables etc but that doesn’t matter here), but for example I wouldn’t be able to call the method “something” without having an instance of that class. I am pretty sure it is the same in rust when a method has self.
@Meatball Can you please, for clarity, provide us with a list of differences between functions and methods in Rust, each one together with a relevant reference to the Rust language reference?
I already provided everything I found, plus a code demo.
If/when you think the reference is wrong or incomplete, please argue why you think so, optionally with code samples. (I do not doubt that the ref is incomplete, and think it plausible that is wrong – just not in ways relevant here.)
This is true in the sense that to call a function, all arguments must be provided, including self. But that’s no different than regular functions. Methods in Rust can be passed around like regular function pointers, which I think you’re saying shouldn’t be possible(?). Methods in Rust really are just syntactic sugar for plain old functions.
In general I think what can be happening is that we are just missunderstanding each other.
A method takes an instance as a parameter aka have self in the begning, a function does not. A method has to be assigned along side a struct, enum or trait.
Rust book: ” Methods are similar to functions: we declare them with the fn keyword and a name, they can have parameters and a return value, and they contain some code that’s run when the method is called from somewhere else. Unlike functions, methods are defined within the context of a struct (or an enum or a trait object, which we cover in Chapter 6 and Chapter 17, respectively), and their first parameter is always self , which represents the instance of the struct the method is being called on”
@senekor Can you get this to compile? Rust Playground
@Meatball The book (note: not the reference) does say «unlike functions», but this is either sloppiness, or associated functions aren’t functions. Will you argue that associated functions aren’t functions? (Wouldn’t be the first time that naming has gone bad.)
I would call them functions since they dont take self.
Associated functions are functions, and methods aren’t, so methods aren’t associated functions?
Yes, the book again: ” All functions defined within an impl block are called associated functions because they’re associated with the type named after the impl . We can define associated functions that don’t have self as their first parameter (and thus are not methods) because they don’t need an instance of the type to work with. We’ve already used one function like this: the String::from function that’s defined on the String type”
I don’t think we need to get into the details of the differences beyond that stated by The Book at this early point.
When people are first learning Python, for example, they don’t have to worry about the differences between functions and methods. Rather, they introduce functions only in the tutorial (section 4.7)[4. More Control Flow Tools — Python 3.11.3 documentation]. Much like The Book, they don’t introduce objects and methods until later.
That approach seems to work for many people learning Rust and other languages like Python.
Not quite. I don’t know if it’s possible to get to a function pointer with the dot syntax. In most situations it’s not needed either, because even in generic code you can refer to the method via the type: Playground
There’s one situations where that’s not the case: with dynamic dispatch. e.g. a function with an argument t: &dyn TrivialTrait. I don’t know how to extract a function pointer from the generated vtable…
Yes, we might have gotten a bit into the weeds. Let’s remember that exercism’s syllabi encourage hand-waving. We should do that for methods. Just mention that they exist, the syntax they can be used with, and be done with it.
Yes, we might have gotten a bit into the weeds. Let’s remember that exercism’s syllabi encourage hand-waving. We should do that for methods. Just mention that they exist, the syntax they can be used with, and be done with it.
This 
Please can we try and keep discussions to the actions that we’re trying to work through and avoid bikeshedding else we are all putting a lot of energy into things that aren’t making the Rust syllabus better! I really want us to do things in a fixed order, else we end up in chaotic discussions that don’t move forward to our destination
So my questions were:
- Does everyone agree with that analysis? What have I missed? (to be clear, I don’t need you all to teach me Rust here - just agree that what I’ve listed are the things we need to teach).
- When we have consensus on that analysis, Dinesh, refine the introductions to achieve the points, and then tell people when you feel they’re ready for review. Then we can all weigh in.
Does anyone else have any other thoughts on things I’ve missed, or should we let Dinesh refine those PRs and we can collectively move onto designing the next exercise?
Assembly-line is missing
Bird watcher too, I think.
I’m guessing Dinesh is not expected to adjust the two exercises (assembly-line and lucians-luscious-lasagna) which he didn’t open a PR for. Should someone else go over these or are we going to do that later?
I think Jeremys idea at the moment is that we get some kind of consensus on what content we have to cover chapter 3 at the moment. So I think we are not to write new content until we have a consensus. But that is just my understanding.
@remise I’m happy for you to go over those two if you’re up for it? Then we can have that whole first set done!
If anyone would like to list out the extra features from Assembly Line and Bird Watcher here too, that’d be great. Just like I did above.
@isDineshHere: You good to update the others?