# Guidelines to distinguish concrete from abstract types

**URL:** <https://discourse.julialang.org/t/guidelines-to-distinguish-concrete-from-abstract-types/19162>\
**Category:** General Usage\
**Created:** [January 1, 2019, 12:55pm UTC](https://discourse.julialang.org/t/guidelines-to-distinguish-concrete-from-abstract-types/19162 "2019-01-01T12:55:57Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![gcalderone](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gcalderone/32/1539_2.png) [@gcalderone](https://discourse.julialang.org/u/gcalderone)\
**Post date:** [January 1, 2019, 12:55pm UTC](https://discourse.julialang.org/t/guidelines-to-distinguish-concrete-from-abstract-types/19162/1 "2019-01-01T12:55:58Z")

</div>

Is there any proposed guideline to name types and distinguish whether is it a concrete or abstract type?

This would be useful to check whether a package has been developed following this rule: [Style Guide · The Julia Language](https://docs.julialang.org/en/v1/manual/style-guide/#Avoid-writing-overly-specific-types-1)

Besides, a method implementation should not be concerned with the specific implementation of a concrete type. Rather, it should only rely on a specific **behaviour** of its argument(s), which may be provided by several concrete concrete types sharing a common ancestor type.

I know that several abstract types have a `Abstract` prefix in their name, hence a _correct_ function signature should be in the form

```julia
function foo(arg1::AbstractBar, arg2::AbstractBaz, arg3::AbstractWhatever)

```

But this looks quite cumbersome to me, I would prefer writing:

```julia
function foo(arg1::Bar, arg2::Baz, arg3::Whatever)

```

and having `Concrete` as prefix to the concrete type name.

Another possibility would be to propose a (non-mandatory) guideline to prepend or append a single character to all abstract type names.

For instance, I would like to write:

```julia
abstract type ∀Bar end
mutable struct Bar <: ∀Bar
  ...
end
function foo(arg1::∀Bar...)

```

since this reminds me that the `foo` function works with any of the subtypes of the _Bar_ entity. And `∀` is an upside down `A` (for abstract…) 😉

However, the `∀` character actually lead to a syntax error, hence it is not a viable option.

Any other proposal/comment?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 1, 2019, 1:24pm UTC](https://discourse.julialang.org/t/guidelines-to-distinguish-concrete-from-abstract-types/19162/2 "2019-01-01T13:24:30Z")

</div>

> [@gcalderone](#):
>
> Besides, a method implementation should not be concerned with the specific implementation of a concrete type. Rather, it should only rely on a specific **behaviour** of its argument(s), which may be provided by several concrete concrete types sharing a common ancestor type.

This is not true in general — sometimes you specify a method for a given set of types precisely because to implement it you need to know about the internals. Eg look at the code for `+(::Rational, ::Rational)`.

If you want to dispatch based on the support for an interface, it may be better to use traits instead of abstract types.

I think that enforcing that type names signal their position in the type tree may not be worth it. Eg currently there are many types that do and many that don’t, eg `AbstractRange` vs `Real` and `Number`.

---

<div class="post-metadata">

**Author:** ![gcalderone](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gcalderone/32/1539_2.png) [@gcalderone](https://discourse.julialang.org/u/gcalderone)\
**Post date:** [January 1, 2019, 6:49pm UTC](https://discourse.julialang.org/t/guidelines-to-distinguish-concrete-from-abstract-types/19162/4 "2019-01-01T18:49:55Z")

</div>

Thanks for the response.

> [@Tamas\_Papp](#):
>
> This is not true in general — sometimes you specify a method for a given set of types precisely because to implement it you need to know about the internals. Eg look at the code for `+(::Rational, ::Rational)` .

I agree it is not true in general, but it should be so for exported methods in a package since the users (other than the package author) are typically not aware of the detailed implementation.

And of course there are notable examples, like the ones you mentioned, for which this guideline would introduce plenty of breaking changes.

I was just wondering if anyone had the same thought, or if a discussion/agreement were reached in some way.

Besides, the `!` convention at the end of functions which modify their arguments is a very convenient approach. So why not extend it to other language aspects?

---

<div class="post-metadata">

**Author:** ![gcalderone](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gcalderone/32/1539_2.png) [@gcalderone](https://discourse.julialang.org/u/gcalderone)\
**Post date:** [January 4, 2019, 10:00am UTC](https://discourse.julialang.org/t/guidelines-to-distinguish-concrete-from-abstract-types/19162/5 "2019-01-04T10:00:35Z")

</div>

> [@gcalderone](#):
>
> I agree it is not true in general, but it should be so for exported methods in a package since the users (other than the package author) are typically not aware of the detailed implementation.

Ops, I think I misunderstood the [guideline](https://docs.julialang.org/en/v1/manual/style-guide/#Avoid-writing-overly-specific-types-1) in the manual: of course we should avoid being too picky on argument types, but there are cases where a method will only work with a **specific implementation** , hence it makes sense to require a specific concrete type. This of course applies also to exported methods.

Given my original understanding was wrong, I believe there is no actual strong motivation for the proposal…