Компилятор такое ест. есть ли в этом какая либо польза?

struct EEw{}
fn test44()-> EEw{
	
	impl EEw{
		pub fn ddddd(){}
	}
	
	EEw{}
}

иногда статик-переменные удобно объявлять внутри функции

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

единственный эффект который я вижу - косметический.

позволяет не используя модулей не захламлять общее пространство.

например если struct EEw используется только при возврате из функции test

соответственно сама структура обязана быть объявлена вне функции, а её impl можно “спрятать” и внутри.
ещё вот так тоже работает

struct EEw{}
fn test()-> EEw{
	static I_AM_STATIC_INSIDE_FN:i32=45;
	impl EEw{
		pub fn ddddd(){}
		pub fn bar(self){
			let foo= I_AM_STATIC_INSIDE_FN;
		}
	}
	
	EEw{}
}

в некоторых случаях может помочь в организации кода …

ХА.
вот так тоже.

struct EEw {}

fn test() -> EEw {
	EEw {}
}

struct Data {}

impl Data {
	fn get_data(self) {


		static I_AM_STATIC_INSIDE_FN: i32 = 45;

		impl EEw {
			pub fn bar(self) {
				let foo = I_AM_STATIC_INSIDE_FN;
			}
		}

	}
}

можно скрытые взаимосвязи организовывать

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

спорное утверждение

1)все IDE поддерживают навигацию по коду.
2) конкретно сейчас озабочен возвратом УТИЛИТАРНЫХ итераторов при запросе данных у поля пакета.
от этих итераторов, кроме функционала ничего ненужно, но приходиться городить структуры которые имплементируют trait Iterator , придумывать им нескучные имена… это приводит к замусориванию кода… ну нет в Rust “анонимных структур” как в JAVA.

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

Может ‘fn get_iter() -> impl Iterator<…>’?

1 лайк

вот я и пытаюсь писать что то типа


fn field_array() -> impl Iterator<Item=i32> {
	
	struct MyIter {
		pub D0: usize,
		d0: usize,
		D1: usize,
		d1: usize,
		D2: usize,
		d2: usize,
	}
		
	impl Iterator for MyIter {
		type Item = i32;
		
		fn next(&mut self) -> Option<<Self as Iterator>::Item> {
			Some(5)
		}
	}
		
	 MyIter { D0: 10, d0: 0, D1: 0, d1: 0, D2: 0, d2: 0 }
}

fn main() {

	for val in  field_array()
		{
			....
		}
}

Ну, как бы, необходимость навигации по коду - признак недостаточной читабельности :slight_smile:
Хотя не отрицаю, что может понадобиться хитрый способ завернуть код.

В свою очередь то, что IDE поддерживают навигацию - само по себе спорное утверждение. Например, в случае макросов и прочей подобной кодогенерации - всё будет достаточно печально ещё достаточно долгое время.


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

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

Ещё, кстати, модули не обязательно выносить в отдельные файлы, они вполне могут сосуществовать в одном файле.

пример кода мало что объясняет. Несколько непонятных целочисленных полей

не зацикливайтесь на деталях, тут важно обратить внимание на то, что все это завернуто в тело функции field_array и снаружи структура MyIter не видна, и не “мусорит” собой общее пространство

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

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

безумием будет, если сразу после континентов вдруг увидеть “муравья”, а потом снова вид с марса.

Ещё, кстати, модули не обязательно выносить в отдельные файлы, они вполне могут сосуществовать в одном файле.

мне модульное устройство Rust страшно нравится, особенно возможность навигации из модуля .
навигацией вниз - никого не удивишь. а вот навигация вверх, к родителю, кто бы он ни был - это реально круто

1 лайк