Примерно по аналогии с Java8, в интерфейсах можно делать реализации методов, единственное что нельзя - хранить состояние. Просто не нужно ключевое слово default писать.

Более менее всё описано в первом абзаце документации: https://kotlinlang.org/docs/reference/interfaces.html#interfaces

я это читал, просто не понимаю причину почему в другом языке говорят что нельзя а тут можно

потому что раньше это в котлине называлось trait, а не interface

Потому что разные языки пишутся для разных целей, в разное время, с различными намерениями.

В той же джаве до 8-й версии интерфейс считался способом исключительно задать контракт. Однако с выходом 8-й джавы есть сдвиг. Интерфейс стал способом задать базу и прямо там же дописать то, что скорее всего будет во всех имплементациях выглядеть одинаково, поскольку опирается на другие функции.

Справедливости ради, я бы сказал, что реализованные функции в интерфейсах нужны редко, чаще всего проще то, что хочется реализовать прямо в интейфейсе, вынести в extension function.

ну хорошо, а для каких задач это сделано то? Почему другие языки не хотят сделать тоже самое? Почему они придерживаются того, что методы должны быть абстрактными?

Пока для меня это тежело доходит, те же стандарты с с ширпа нарушаются тут и я не понимаю по каким причинам

а еще в котлиновских интерфейсах могут быть свойства

это да, тогда не понятна роль абстрактного класса ведь для меня это то, что их отличало

Так ещё раз - интерфейсы в одних языки это просто контракты, в других - stateless описание, где допустимо что-то реализовать на основе других функций.

И таки какая разница какие стандарты в Шарпах, если мы говорим о Котлине? Языки разные и это нормально. Мы же не обсуждаем почему Котлин не похож на Лисп или Си или Хаскель :)

Интерфейс - Stateless описание (можно описать контракты, можно реализовать функции на основе других, нельзя хранить состояние [речь про хранение в field, не про property], нету конструкторов)
Абстрактный класс - Stateful описание (можно описать контракты, можно реализовать функции на основе других, можно хранить состояние, есть конструктор, нельзя реализовывать несколько абстрактных классов)

Ты прав.
Интерфейсы есть механизм построения абстракций в языках типа java и c#, в которых запрещено множественное наследование. Наследоваться можешь только от одного класса, а имплементить сколько угодно интерфейсов. Тем самым решается проблема множественного наследования реализации. Цена вопроса - интерфейс не может содержать имплементацию методов.
Позже в java 8 для реализации stream api в коллекциях пришлось придумать понятие "дефолтного" метода в интерфейсах. Проблема множественного наследования реализации всплыла, но решалась малой кровью на уровне компилятора.
При чем тут java? Рассматривай котлин как "наследника" или "следующую ступень эволюции" java.
Задавая вопрос "почему именно так реализовано", ты ступаешь на зыбкую почву "у каждого свое мнение" и рискуешь разжечь кострище холивара.
Мой совет: прими как данность, что интерфейс может иметь дефолтные методы. И никогда это не используй (пока не достигнешь черного пояса по котлину)

Это отголоски джавы.
Раньше интерфейсы не имели дефолтных методов и для значений по умолчанию использовались только абстрактные классы.
Но для обратной совместимости в Java 8 были вынуждены добавить в интерфейсы дефолтные реализации методов, т.к было невозможно добавить новые методы к интерфейсу (например List) не нарушая уже существующих реализаций.

codewars, если коанов маловато

По тому что есть \n, а располагать несколько инструкций на одной строке - плохо с точки зрения читабельности

Дефолтная реализация интерфейса. Это стильно модно молодёжно - даже в C# скоро завезут

Класс хранит состояние, а интерфейсное свойство - это только геттер-сеттер без backing field

Раньше это был вопрос для прошаренных - чем отличается абстрактный класс от интерфейса

это невероятно тупой вопрос на знание основ теории

Что поделать, плохих студентов этим валили

Мы сейчас плохих студентов валим при помощи ienumerable и yield return