История изменений

Исправление LINUX-ORG-RU, 15.03.25 15:47 (текущая версия) :

Ну, сомневаюсь что моё мнение тут будет полезно и что-то значит, но уж раз спросил, во первых как по мне плюсовый вариант :: не надо, слишком жирное написание, а foo::bar::baz::camaz выглядит вообще ужасно.

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

Удобство в том что когда например возвращаем файл, можно возвращать не примитив вроде просто числа как дескриптора, а структуру (указатель на неё), с полями которые обрабатывают эту же структуру данных.

Ещё удобство в том что в неком роде это решает проблемы именований, если есть несколько типов данных которым мы хотим задать значение то

  type_foo:set("lala")
  type_bar:set(42)

иногда, лучше чем

type_foo_set(type_foo,"lala")
type_bar_set(type_bar,42)

Так set являясь полем может быть легко переопределена, динамически например.
Банальная ситуация, есть у тебя файл и например сетевой сокет, оба могут быть буферизированы и обоим нужно иногда сделать принудительный сброс данных дальше на обработку, семантически это одно и тоже flush и выбора тут два. Первый, представлять всё как файл, строить высокую абстракцию и передавать


flush(file)
flush(socket)

А различать что есть что уже внутри flush, а на уровне кода различать именованием. Или делать просто отдельные именованные вызовы для типа данных

file_flush(file)
socket_flush(socket)

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

file = newfile()
file:write("lala")
file:flush()

socket = newsocket()
socket:send("lala")
socket:flush()

Тут важнее ещё то что можно будет сделать так

if(getos() == "linux")
{
    file.flush = linux_flush;
}

например, в иных вариантах нужен будет либо препроцессор, либо

   if(getos() == "linux")
   {
       file_flush = linux_flush;
   }

А тут чревато уже может быть.

Я за стиль №2, там визуально видно, чего куда, если уж делать, тут явное разделение обращение к полю как к полю и как только к вызову с неявным аргументом, нужно и то и то порой.

Иными словами, как по мне нет проблем в записи strbuf_append_cstr4 и buf:append_cstr4 в целом разницы то никакой, разница она появляется как следствие, в динамике написания кода. Ну и первый вариант быстрее, даже на просто уровне обработки до компиляции, так что если и привносить косвенный первый аргумент в функции, то оставить и возможность первого варианта, обычного вызова, обычной функции с обычными аргументами, напрмимер в той же Lua дохренища вариантов сделать и так и сяк и эдак, но я часто пишу на Lua как на Си, ну просто такой подход тупо быстрее работает. Например

m3 = matrix_pow(m1,m2)

вместо

m1:pow(m2)

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

Но никто не помешает сделать так

m3 = m1.pow(m1,m2)

Но в любом случае это палка о двух концах

а если у нас есть args/argc то какое количество аргументов мы будем сообщать с учётом неявного аргумента или без его
нужно ключевое слово обращения к неявному аргументу
как обрабатывать ситуации если через : делается вызов функции у которой единственный аргумент и он не является структурой данных/типом данных который передаётся неявно.
можно ли через : вызывать функцию которая не является полем, а просто левой функцией

foo(x) 
{
  print(x+x)
}

bar = {"hello"}

bar:foo() ????????? \o_0/ ! ! \0_O\

И так далее. Как по мне, прежде чем реализовать, нужно пройтись по всем «последствиям» и теоретическим констуркциям которые вдруг будут записаны программистом, так как чисто синтаксически они вполне себе могут быть :D

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

Типа такого. Мысли в слух.

Исходная версия LINUX-ORG-RU, 15.03.25 15:37:

  type_foo:set("lala")
  type_bar:set(42)