можно хранить в новом типе (строка + длина) и не давать запускать конструктор, если длина не соответствует длине строки

а можно вообще параметризовать по длине тип

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

это к старому вопросу об интерпретировании куска файла как идущих подряд значений. тут есть строка по 8 и строка по 4 знака.

раз можно делать reinterpret_cast к базовым типам, то как поступить со строкой

Ммм... Так там же строк вообще не должно быть? Только Vector{UInt}

непонятна задача )
из файла можно читать фиксированное число байт, хотите 8 читайте, хотите 4

+

Я попозже опишу

Строка фиксированной длинны имеет смысл с соответвующим форматом хранения. Если у тебя колонка типа строка и ты ее хранишь не как массив указателей на строки, а как непрерывный массив байт.

Есть вот такой пакет https://github.com/JuliaData/WeakRefStrings.jl, который хранит массив строк разной длины как непрерывный массив байт. Достоинства - легко сохранять/читать с диска и вообще передавать куда-нибудь в бинарном виде, недостатки очевидны - либо все строки в этом массиве и их порядок неизменяемы, либо каждое изменение приводит к  полному копированию массива с внесением изменений

Nice. Thanks a lot

Скажем прочитал я из файла кусок длинной 32 байт. В нем идущие подряд значения одного типа. если они real или double, то скажем я использую reinterpret_cast с типом Float32/Float64, и блок конвертируется в массив 8 значений Float 32 либо же 4 значения Float 64. Как мне дешевле/проще всего проинтерпретировать такой же блок на строки фиксированной длины 4 или 8 символов.

Usage of WeakRefStrings is discouraged for general users.

Насколько я помню, WeakRefString - это какие-то остатки ещё до 0.6

Смотря что нужно потом с этими строками делать. В общем случае нарезать руками как-нибудь типа push!(res, String(view(raw, <begin>:<end>)))

>Usage of WeakRefStrings is discouraged for general users.
Как я понимаю тут речь о том, что это внутренний класс. Что логично, потому что представление массива строк непрерывным массивом байт очень специфичная задача и приводит к довольно неочевидному поведению. Например каждое сравнение элемента из этого массива с другой строкой будет приводить к аллокации (во всяком случае в 1.3, но думаю ничего с тех пор не поменялось). Потому что при WeakRefStrings[ind] собственно происходит неявное создание строки по типу String(view(raw, offset:limit))

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

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

Я когда экспериментировал с DataFramesDb подобный же класс написал и пытался его сделать удобным именно как тип колонки в памяти, но не получилось, возникают либо неочевидные аллокации, либо интерфейс перестает напоминать массив строк. Поэтому оставил его как внутренний класс в который удобно либо загнать массив обычных строк и на выходе получить массив байт, либо наоборот - загнать в него массив байт и с помощью collect получить массив строк. Думаю мотивация и назначение у WeakRefString довольно похожее.
Привел я его просто как пример а не как рекомендацию к использованию