Is There Any Reason to Use This-≫

Is there any reason to use this-

To guarantee you trigger compiler errors if there is a macro that might be defined with the same name as your member function and you're not certain if it has been reliably undefined.

No kidding, I'm pretty sure I've had to do exactly this for that reason!

Use of this keyword in C++

Yes, it is not required and is usually omitted. It might be required for accessing variables after they have been overridden in the scope though:

Person::Person() {
    int age;
    this->age = 1;
}

Also, this:

Person::Person(int _age) {
    age = _age;
}

It is pretty bad style; if you need an initializer with the same name use this notation:

Person::Person(int age) : age(age) {}

More info here: https://en.cppreference.com/w/cpp/language/initializer_list

When do you use the this keyword?

There are several usages of this keyword in C#.

To qualify members hidden by similar name
To have an object pass itself as a parameter to other methods
To have an object return itself from a method
To declare indexers
To declare extension methods
To pass parameters between constructors
To internally reassign value type (struct) value.
To invoke an extension method on the current instance
To cast itself to another type
To chain constructors defined in the same class

You can avoid the first usage by not having member and local variables with the same name in scope, for example by following common naming conventions and using properties (Pascal case) instead of fields (camel case) to avoid colliding with local variables (also camel case). In C# 3.0 fields can be converted to properties easily by using auto-implemented properties.

Is there any reason to use [: over @:?

Some people prefer ([: f g) to f@:g for readability, perhaps because it is more spread out, although f @: g accomplishes the same spacing without parentheses.

I am pretty sure that I have seen cases where it made a difference to the outcome, but I can't remember them now. Perhaps others will be able to come up with examples where they differ.

Is there any reason to use the 'return' in the second line in the method ?

The main reason to use the first way is to reduce nesting in your source file.

Is there ever a reason to use is versus as?

You must use is instead of as when the destination type is a non-nullable value type:

object obj = 0;
int i = obj as int; // compilation error because int can't represent null

if (obj is int)
{
    int j = (int)obj; // works
}

Is there any reason to use suspend fun fn(...): Either Throwable, A instead of suspend fun fn(...): A?

If you want to work with Throwable there are 2 options, kotlin.Result or arrow.core.Either.

The biggest difference is between runCatching and Either.catch. Where runCatching will capture all exceptions, and Either.catch will only catch non-fatal exceptions. So Either.catch will prevent you from accidentally swallowing kotlin.coroutines.CancellationException.

You should change the code above to the following, because either { } doesn't catch any exceptions.

suspend fun log(message: String): Either<Throwable, Unit> =
  Either.catch { println(message) }

suspend fun add(sum1: Int, sum2: Int): Either<Throwable, Int> =
  Either.catch { sum1 + sum2 }

Is there any reason to prefer suspend fun fn(...): Either<Throwable, A> over suspend fun fn(...): A?

Yes, the reason to use Result or Either in the return type would be to force the caller to resolve the errors. Forcing the user to resolve an error, even within IO<A> or suspend is still valuable since try/catch at the end is optional.

But using Either becomes truly meaningful to track errors across your entire business domain. Or resolve them across layers but in a typed way.

For example:

data class User(...)
data class UserNotFound(val cause: Throwable?)

fun fetchUser(): Either<UserNotFound, User> = either {
  val user = Either.catch { queryOrNull("SELECT ...") }
   .mapLeft { UserNotFound(it) }
   .bind()
  ensureNotNull(user) { UserNotFound() }
}

Is There Any Reason to Use This-≫