Эти конструкции эквивалентны или нет?

public static class ClassConst 
{
  public const int Zero = 0;
}

public struct StructConst 
{
     public const int  Zero = 0;
}

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

Р>Эти конструкции эквивалентны или нет?

Для улучшения вопроса рекомендую самому попробовать ответить (и поделиться) на ваш вопрос и показать, в чём у вас вознилка сложность
Что заставляет вас сомневаться в том, эквивалентны ли они или нет?

Вообще на этом сайте уже более 20 лет доступна полезнейшая статья Как правильно задавать вопросы. Следуя этому руководству вы сами сможете научиться отвечать на большую часть своих вопросов (если есть такая цель, конечно).

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

Р>Эти конструкции эквивалентны или нет?

Эквивалентны, если речь идет о доступе к константе. В данном случае и класс, и структура выступают в роли пространства имен для константы, а в код (где используется константа) подставляется её значение (т.е. сама константа инлайнится).

Неэквивалентны, если речь идет о переменной данного типа. Класс будет размещен в хипе, а структура в стеке (или в хипе при боксинге). Но константа тогда тут не причем.

Маразм Шарпа в том, что в нем нельзя объявить константу вне типа и тип используется в качестве пространства имен. По уму можно было допустить объявление:

namespace X
{
  public const int Zero = 0;
}

Но тогда CLR пришлось бы расширять первоклассной сущностью — константой. На этом решили сэкономить допустив только типы.

По той же причине сделали маразм с отсутствием глобальных функций (не методов).

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

VD>Маразм Шарпа в том, что в нем нельзя объявить константу вне типа и тип используется в качестве пространства имен.
VD>По той же причине сделали маразм с отсутствием глобальных функций (не методов).

А в чём тут "маразм"?

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

Р>Эти конструкции эквивалентны или нет?
Есть различие в отсутствии static struct, когда компилятор не даст добавить нестатический член.

using System;

// using static применимо ко всем
using static SC;
using static C;
using static S;

public static class SC
{
    public const int ISC = 1;
    // int x = 1; ошибка компиляции
}

public class C
{
    public const int IC = 1;
    int x = 1; // можно
}

public struct S
{
    public const int IS = 1;
    int x; // можно
}

class Program
{
    public static void Main()
    {
        int i = ISC + IC + IS;
    }
}

sharplab.io

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

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

VD>>Маразм Шарпа в том, что в нем нельзя объявить константу вне типа и тип используется в качестве пространства имен.
VD>>По той же причине сделали маразм с отсутствием глобальных функций (не методов).

_FR>А в чём тут "маразм"?

Не столько маразм, сколько неудобство и сопутствующие идеологические костыли в виде введения такого понятия, как статический класс (канонический пример System.Math)

Например, такой записи:

double Func(double x)
{
    return Math.Truncate(Math.Sqrt(x * Math.PI));
}

я бы предпочёл нечто вроде:

double Func(double x) using Math
{
    return Truncate(Sqrt(x * PI));
}

(причём как в этом примере, с возможностью "раскрывать" namespace-ы в пределах функции).

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

VD>>>Маразм Шарпа в том, что в нем нельзя объявить константу вне типа и тип используется в качестве пространства имен.
VD>>>По той же причине сделали маразм с отсутствием глобальных функций (не методов).
_FR>>А в чём тут "маразм"?

4>Не столько маразм, сколько неудобство и сопутствующие идеологические костыли в виде введения такого понятия, как статический класс (канонический пример System.Math)
4>я бы предпочёл нечто вроде:

4>double Func(double x) using Math
4>{
4>    return Truncate(Sqrt(x * PI));
4>}

Так using static Math; вам в помощь (sharplab):

using static System.Math;

public class C
{
  double Func(double x) => Truncate(Sqrt(x * PI));
}

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

_FR>А в чём тут "маразм"?

В том, что тип используется не по назначению. И нельзя обойтись без него, хотя никакой необходимости в нем нет.

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

_FR>Так using static Math; вам в помощь (sharplab):
_FR>

_FR>using static System.Math;

_FR>public class C
_FR>{
_FR>  double Func(double x) => Truncate(Sqrt(x * PI));
_FR>}
_FR>

Спасибо, не знал, что это (using static) пришло ещё в рамках C# 6 (2015 год), но как видите, получается надо было сначала создать проблему, чтобы через 14 лет её решить.

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

_FR>>А в чём тут "маразм"?

VD>В том, что тип используется не по назначению. И нельзя обойтись без него, хотя никакой необходимости в нем нет.

Тут сложно сказать, есть ли необходимость или нет, в том плане, что для константы может и нет необходимости, но она может быть для пользователя (программиста).

Константа по сути это статическое ридонли поле. По идее на уровне пространства имён можно было бы разрешить объявлять поля (и константные и даже нет — а что, просто глобальная переменная), и методы и всё что угодно (ну странно разрешать просто методы и толшько константы и не позволять не-константные поля типа decimal или там DateTime, object, etc).

// Например какой-либо дот.нет ориентированный язык мог бы это даже поддержать на своём уровне, под капотом просто оборачивая это всё в некий скрытый от пользователя "статический класс"

Мне кажется, это усложнило бы спеку рантайма/метаданных, сценарии перегрузки и разрешения имён (одна и так из самых не простых тем), пришлось бы задать правила инициализации таких полей (может и конструктор неймспейсу понадобился бы?), рефлекшен, какие-то ещё сценарии.

Скорее всего привело бы к рекомендациям объвлять подобные методы в своём под-пространстве имён (как сейчас их объявляют просто в классе):

namespace System.Math;

public const double PI = 4;

public static double Sqrt(double value) => value - 1;

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

Если народ начнёт валом добавлять полезности в System, который ну в очень большщом числе файлов юзается, конфликты неизбежны. Это будет проблемой и для пользователя и для разработчиков языков, которым нужно будет искать какие-то пути уменьшения проблем от этого.

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

ну ты и зануда !!!

Здравствуйте, VladD2, Вы писали:
VD>Но тогда CLR пришлось бы расширять первоклассной сущностью — константой. На этом решили сэкономить допустив только типы.
CLR уже расширен.
VD>По той же причине сделали маразм с отсутствием глобальных функций (не методов).
И глобальные функции в CLR тоже есть.
Отсутствие поддержки для них — решение именно C#.

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

_FR>Мне кажется, это усложнило бы спеку рантайма/метаданных, сценарии перегрузки и разрешения имён (одна и так из самых не простых тем), пришлось бы задать правила инициализации
таких полей (может и конструктор неймспейсу понадобился бы?), рефлекшен, какие-то ещё сценарии.

Спецификацию это никак бы не расширило просто потому что в .NET метаданных уже есть концепция "модуля" который и представляет собою статический класс.

_FR>чтобы пользователь ненароком не подключил бы что-то, что вызовет конфликты с другими определениями. А может и того хуже — не конфликты, а втихую перегрузка отработает не ожиданным для пользователя виде.

Механизмы разруливания конфликтов в виде extern alias в .NET представлены искаропки.

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

S>CLR уже расширен...
S>Отсутствие поддержки для них — решение именно C#.

Ну найди таблицы метаданных отвечающие за глобальные функции и константы. Глобальные функции и константы есть только в С++ и они там тупо анменеджед.

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

_FR>Константа по сути это статическое ридонли поле.

Полнейшая чушь. Константа — это именованное значение. Для него поля не нужны.

_FR>По идее на уровне пространства имён можно было бы разрешить объявлять поля (и константные и даже нет — а что, просто глобальная переменная), и методы и всё что угодно (ну странно разрешать просто методы и толшько константы и не позволять не-константные поля типа decimal или там DateTime, object, etc).

Дальнейшие рассуждения просто бессмысленны. Да и кому интересны рассудения в стиле "По идее можно было бы разрешить..."? Можно все что не противоречит логике.

_FR>// Например какой-либо дот.нет ориентированный язык мог бы это даже поддержать на своём уровне, под капотом просто оборачивая это всё в некий скрытый от пользователя "статический класс"

Эмуляция эмуляции.

_FR>Мне кажется, это усложнило бы спеку рантайма/метаданных, сценарии перегрузки и разрешения имён (одна и так из самых не простых тем), пришлось бы задать правила инициализации таких полей (может и конструктор неймспейсу понадобился бы?), рефлекшен, какие-то ещё сценарии.

Ага. Спека CLR — это огромная книга. В ней добавилось бы полстраницы.

_FR>Скорее всего привело бы к рекомендациям объвлять подобные методы в своём под-пространстве имён (как сейчас их объявляют просто в классе):

Логично и что?

_FR>чтобы пользователь ненароком не подключил бы что-то, что вызовет конфликты с другими определениями. А может и того хуже — не конфликты, а втихую перегрузка отработает не ожиданным для пользователя виде.

Вызовет конфликт, получит ошибку времени компиляции как и с любым другим именем. У констант вообще проблем нет. Они на стадии компиляции превращаются в значения.

_FR>Если народ начнёт валом добавлять полезности в System, который ну в очень большщом числе файлов юзается, конфликты неизбежны. Это будет проблемой и для пользователя и для разработчиков языков, которым нужно будет искать какие-то пути уменьшения проблем от этого.

Хватит фантазировать. Никаких оправданий этому решению нет. Просто сделали как захотели.

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

VD>Ну найди таблицы метаданных отвечающие за глобальные функции и константы.
https://learn.microsoft.com/en-us/dotnet/api/system.reflection.module.getmethods?view=net-8.0
https://learn.microsoft.com/en-us/dotnet/api/system.reflection.module.getfield?view=net-8.0

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

_FR>>А в чём тут "маразм"?

VD>В том, что тип используется не по назначению. И нельзя обойтись без него, хотя никакой необходимости в нем нет.

Ну рефлексию надо расширять, Namespace привязывать к сборке итд

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

_FR>>Мне кажется, это усложнило бы спеку рантайма/метаданных, сценарии перегрузки и разрешения имён (одна и так из самых не простых тем), пришлось бы задать правила инициализации
_FR>>таких полей (может и конструктор неймспейсу понадобился бы?), рефлекшен, какие-то ещё сценарии.
H>Спецификацию это никак бы не расширило просто потому что в .NET метаданных уже есть концепция "модуля" который и представляет собою статический класс.

Хм. Учитывая то, как Влад трактует ответы ему, я уже боюсь (не хочу) рассуждать свободно: разве в модуль может быть вложен в другой модуль (класс же может быть объявлен внутри другого класса)?
И я не уверен, что модуль это именно то, что нужно Владу: ему, как мне показалось, хочется иметь возможность декларировать константы (и методы и [не вижу причин не позволять] всё остальное) на уровне пространства имён, а не модуля. модуль же просто контейнер для типов и нужен не столько для логического разделения типов, сколько для физического (например если часть типов в нашей одной сборке собирается одним компилятором, а часть другим). Строго говоря, разница будет.

Логически же (как я и сам это понимаю) да, так почти и есть, об том я и сказал: реализовать то, чего не хватает Владу в каком-либо .NET-языке можно "фейковым" статическим классом (опять же строго говоря abstract sealed) в нужном пространстве имён: то, что Влад попросил можно самим сделать в виде скрытого от пользователя статического класса, расширения метаданных не требуется.

С точки зрения языка C# мне кажется это вызовет дополнительные трудности. На сколько большие не не возьмусь судить.

_FR>>чтобы пользователь ненароком не подключил бы что-то, что вызовет конфликты с другими определениями. А может и того хуже — не конфликты, а втихую перегрузка отработает не ожиданным для пользователя виде.
H>Механизмы разруливания конфликтов в виде extern alias в .NET представлены искаропки.

"extern alias" (если я правильно понял о чём речь) на сколько мне известно позволяет решать конфликты между именами типов (в одних и тех же пространствах имён) в различных сборках и я не вижу, как он бы помог тут.

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

VD>>Ну найди таблицы метаданных отвечающие за глобальные функции и константы.
S>https://learn.microsoft.com/en-us/dotnet/api/system.reflection.module.getmethods?view=net-8.0
S>https://learn.microsoft.com/en-us/dotnet/api/system.reflection.module.getfield?view=net-8.0

Это, с определённой точки зрения, совсем не то же самое, что и методы и поля на уровне пространств имён (неймспейсов по-нашему).
Модуль, концептуально, это больше про физическое разделение кода, а пространства имён — про логическое. Я б не стал одно через другое.

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

_FR>>Скорее всего привело бы к рекомендациям объвлять подобные методы в своём под-пространстве имён (как сейчас их объявляют просто в классе):

VD>Логично и что?

То, что в таком случае никакой разницы между

using SomeNamespace.MyGlobalConstantsAndMethods; // Явное подключение этого самого "под-пространства имён" в воображаемой версии C#

и

using static SomeNamespace.MyGlobalConstantsAndMethods; // Подключение статического класса с константами и методами в C# 6

я не вижу