Clarity on struct vs type

documentation

#1

I’m just learning Julia, and I’m finding the docs not so clear on the differences between type and struct. In the docs there are no real examples of declaring custom types using the type keyword, instead there’s a section on composite types using struct. So I’m just pointing out that as a beginner the docs are leaving me with questions:

  1. What is the difference between using struct and type, or mutable struct and type?
  2. Why would you choose one over the other? Why is struct used in the docs rathe than type?

#2

type (and immutable) are deprecated, just use mutable struct (or just struct).


#3

Cool, answers my question. I wasn’t getting any deprecation warnings (using 0.6.2).

Feels a bit unnatural to me to me, personally type seemed more sensible, but looks like there was a long discussion about it on #19157

EDIT: Actually, being more honest, this is the first thing I’ve come across in Julia which just seems flat out ugly.


#4

I will not comment on the aesthetic part (I happen to like struct), but note that “type” is used in another, very specific sense by Julia (the thing that dispatch operates on, etc), so using it for composite types was just confusing.


#5

Sure thing. I’m a beginner here so can’t see the bigger picture. Very much enjoying my journey though. Loving Julia so far :slight_smile:


#6

Have been aware that type is noted to become deprecated in 0.7.0-alpha. Does this mean that an overhaul is due in the type section of the Docs?


#7

AFAICT it has already been updated, I see no mention of type or immutable.


#8

Sorry, I’m just a beginner. IIUC, the concept of type is not deprecated; it is only that the users shouldn’t define any type and they should use struct instead?


#9

It was just a name change, to be clearer and more consistent, nothing else changed.

type -> mutable struct
immutable -> struct

(edit: it was also to make the preferred type of struct, immutable, to be the “default”)


#10

Then all the words types shall be replaced by mutable struct in both the Docs and any actual Julia code?


#11

No, when the docs are talking about the concept of a type, then it doesn’t change (and this was a big part of why the change was necessary, the confusion when talking about a specific kind of type, i.e. a structure that might be mutable or immutable, vs. abstract types, primitive types, etc., or talking about the concept).

In your code (but not in any doc strings discussing the concept :grinning:), yes, replace immutable => struct, and type => mutable struct.


#12

Thanks for the clarification. (This) confusion dispelled.

Now, bear with me for slightly abusing this thread for a quick question regarding the same doc file:

The first sentence in this section is

Abstract types cannot be instantiated, …

A few paragraphs later, it says

When no supertype is given, the default supertype is Any – a predefined abstract type that all objects are instances of and all types are subtypes of.

Are they contradictory? Confused.


#13

OK, I see your point, that is a bit unclear.
I believe, when it says “all objects are instances of”, simply means that the release isa Any is always for any object. (isa being true for instances of a particular type or subtype of the given type), so not really contradictory.

So, 1 is an instance of an Int, and it’s an instance of a Signed type, an Integer type, a Number type, and Any.


#14

Thanks! I kind of understand what you mean. So probably the second sentence can be rephrased as the following?

When no supertype is given, the default supertype is Any – a predefined abstract type that all objects are instances of the concrete subtypes of and all types are subtypes of.


#15

I’m not the best on documentation, one of the core people might be better at a good description.
You might want to bring it up on slack, or make a PR to change that in the documentation.


#16

Thanks, buddy!! Will raise the point on slack. Thanks!


#17

I think the meaning is that a is an instance of a concrete type, but it is also descended of a number of abstract types.


#18

Yes, I second!