Почему во втором случае возникает ошибка?

module Program
{
    fun1[T]():T where T:new()
    {
        T()
    }
    
  Main() : void
  {
      def fun2[T]():T where T:new()
        {
            T()
        }
          
        def t1=fun1.[int](); //ok
        def t2=fun2.[int](); //Error: don't know how to apply generic specifier to fun2.[?]
  }
}

Здравствуйте, Ka3a4oK, Вы писали:

KK>Почему во втором случае возникает ошибка?

Похоже на баг. Добавь в исью.

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

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

Ну, а локальные функции — это средство декомпозиции и инкапсуляции реализации методов.

Так что у меня давно зреет желание запретить обобщенные локальные функции.

Здравствуйте, VladD2, Вы писали:

VD>Так что у меня давно зреет желание запретить обобщенные локальные функции.

+1
Все равно вывод типов для них нормально не работает.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Ka3a4oK, Вы писали:

KK>>Почему во втором случае возникает ошибка?

VD>Похоже на баг. Добавь в исью.

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

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

VD>Ну, а локальные функции — это средство декомпозиции и инкапсуляции реализации методов.

VD>Так что у меня давно зреет желание запретить обобщенные локальные функции.
Не надо. Пусть будут. Реально иногда бывает полезно.

Здравствуйте, Ka3a4oK, Вы писали:

VD>>Так что у меня давно зреет желание запретить обобщенные локальные функции.
KK>Не надо. Пусть будут. Реально иногда бывает полезно.

С этого места подробнее. Эти юзкейзы неочевидны.

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, Ka3a4oK, Вы писали:

VD>>>Так что у меня давно зреет желание запретить обобщенные локальные функции.
KK>>Не надо. Пусть будут. Реально иногда бывает полезно.

H>С этого места подробнее.
Ну вот мне понадобилось Завтра если будет время, напишу модель кода в котором мне это понадобилось.

H>Эти юзкейзы неочевидны.
Это первое что пришло мне в голову, т.е. для меня это было очевидно.

Здравствуйте, Ka3a4oK, Вы писали:

KK>Не получится. Там внутри функции другой класс типизируется дженерик параметром. А функция вообще без параметров.

Причем тут внутри функции? Я про место применения. В параметры типа ты же int передаешь?

KK>Там совсем частный функционал. В библиотеке он не нужен. Я просто сделал ее нелокальной.

Если он частный, то почему у него параметры типов? Частный он же предполагает однократное применение. А параметры типов сразу предполагают многократное применение.

Можно поглядеть на этот код более детально?

VD>>Ну, а локальные функции — это средство декомпозиции и инкапсуляции реализации методов.

VD>>Так что у меня давно зреет желание запретить обобщенные локальные функции.
KK>Не надо. Пусть будут. Реально иногда бывает полезно.

Откровенно говоря не очень согласен. Но удалять конечно будем только если будет общее согласие по этому вопросу.

Здравствуйте, Ka3a4oK, Вы писали:

Сколько будет "фича" — столько и будут задаваться вопросом:
Issue 661
Issue 838
Issue 916
Issue 1335

Либо выкинуть, либо чинить.

Кто-то чинить имеет желание ?

Здравствуйте, hardcase, Вы писали:

VD>>>Так что у меня давно зреет желание запретить обобщенные локальные функции.
KK>>Не надо. Пусть будут. Реально иногда бывает полезно.

H>С этого места подробнее. Эти юзкейзы неочевидны.

Например, удобно делать так:

def stringBuilder = StringBuilder();
def Append['T](fragment) { _ = stringBuilder.Append(fragment) }

Здравствуйте, Don Reba, Вы писали:

DR>Например, удобно делать так:

DR>

DR>def stringBuilder = StringBuilder();
DR>def Append['T](fragment) { _ = stringBuilder.Append(fragment) }
DR>

Мимо...

def stringBuilder = StringBuilder();
def Append(fragment : object) { _ = stringBuilder.Append(fragment) }

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, Don Reba, Вы писали:

H>Мимо...
H>

H>def stringBuilder = StringBuilder();
H>def Append(fragment : object) { _ = stringBuilder.Append(fragment) }
H>

Но ведь у StringBuilder.Append много перегрузок, а если фрагмент всегда object, то будет использована одна и будет боксинг.

Здравствуйте, i1yich, Вы писали:

H>>Мимо...
H>>

H>>def stringBuilder = StringBuilder();
H>>def Append(fragment : object) { _ = stringBuilder.Append(fragment) }
H>>

I>Но ведь у StringBuilder.Append много перегрузок, а если фрагмент всегда object, то будет использована одна и будет боксинг.

Можно добавить метод-расширениt вроде:

  public Append2[T](this builder : NStringBuilder, value : T) : void
  {
    _ = builder.Append(value.ToString())
  }

Он избавит от боксинга. Название мне только не нравится.

Можно даже в модуль Nemerle.Utility.NStringBuilderExtensions его добавить, чтобы все могли пользоваться.

Ну, а можно макру накатать, которая создаст по методу расширения на каждый метод возвращающий свой тип из заданного класса. Хороший пример для изучения макросов.