решить можно?
Как он может быть по спеке если ты внезапно можешь нарушить спеку и не заметить?
Где будет нарушение спеки? Там нет описания методов tobytearray
А метод уже есть и прямо в типе. И он расходится с tostring
Я бы так сказал, у обоих решений есть очевидные плюсы и минусы. Моя главная претензия даже не к спеке (хотя это важно!), А к тому что пользоваться этим будет тяжело. Новым типом пользоваться (мне) будет удобнее в разы. Вот и всё
А норм будет выглядеть система типов с дублирующимися типами?
У нас есть дублирующиеся фреймоврки. MVC и MVC Core. И в целом проблемы с дублированием понятны
Лучше, чем система с плохо задизайненным единственным
У нас ещё 4 вида разоров
Для обывателя почти не заметно к слову.
А linq вообще на том стоит
Вот эта плохозадизайненность она где-то в специфике имплементации. Снаружи это уникальный идентификатор размера 16 байт
Снаружи есть tobytearray(), никакого "внутри"
Оказывается что снаружи это не просто 16 байт, иначе это был бы byte[16]
Ну он есть, да. И этот метод никогда не будет расово верным потому что есть разные байтовые представления (кодировки). Методу объявят анафему
Есть еще слова «сортируемый». И кому то это тоже важно
Или тупая структура внутри с тем же byte[16] или эквивалентом
Мы уже выше выяснили что сортируемость можно достичь и у гуида
Мог бы быть, если бы не был заточен под variant2
При том что нет повода объявлять ему анафему ели рассматривать Guid сугубо в контексте MS стека с COM, OLE и WinAPI. 0 причин его обсолетить.
Претензия что это error prone и предлагается бойлерплейт чтобы с этим работать. Мне предлагаемое решение моей проблемы не нравится, я против
уточню, я бы с удовольсвием послушал про случаи когда это добавляло проблем в поддержке команде дотнета, я уверен у людей есть примеры, просто их со стороны МС не озвучили
Два типа это не error prone?
Я о том в ишью и написал
это другой класс ошибок
В меньшей степени чем два новых метода с косяками от старых
Обсуждают сегодня