struct 선택 기준

구조체 형태는 필드 의미, 타입 구분, 상태 필요성으로 고른다

이름 있는 필드 구조체, 튜플 구조체, 유사 유닛 구조체는 모두 데이터를 묶지만 읽기 의미와 소유권 규칙이 다릅니다.

필드 이름이 의미를 지킴

user.email처럼 이름으로 값을 읽어야 하면 일반 구조체가 맞습니다.

타입 이름이 구분을 만듦

같은 (i32, i32, i32)라도 ColorPoint는 다른 타입입니다.

값 없이 역할만 표시

상태 저장이 필요 없으면 struct AlwaysEqual;처럼 타입만 세웁니다.

형태 선택 판단표

순서 선택 문법 신호 읽는 기준
01 이름 있는 필드 struct User { email: String } 필드 순서보다 이름이 중요하고, 점 접근으로 의미가 바로 보여야 합니다.
02 필드 초기화 축약 User { email, active: true } 매개변수 이름과 필드 이름이 같으면 중복을 줄여 생성 의도를 드러냅니다.
03 구조체 업데이트 User { email, ..user1 } 남은 필드를 재사용하되 String 같은 소유 타입은 이동될 수 있습니다.
04 튜플 구조체 struct Color(i32, i32, i32); 필드 이름보다 타입 이름으로 도메인을 구분하는 편이 더 짧고 명확합니다.
05 유사 유닛 구조체 struct AlwaysEqual; 저장 데이터 없이 타입의 존재와 트레이트 구현만 필요할 때 선택합니다.

소유권 선택

  • String 필드는 구조체 인스턴스가 데이터를 소유합니다.
  • &str 필드는 수명 표기가 필요하므로 아직 배우기 전에는 String으로 잡는 편이 단순합니다.
  • ..user1은 소유 타입 필드를 옮길 수 있고, bool 같은 복사 타입은 복사됩니다.

컴파일러가 지키는 경계

필드 이름 오타, 타입 불일치, 불완전한 초기화, 이동 뒤 재사용은 구조체 정의와 인스턴스 생성 단계에서 바로 드러납니다. 그래서 구조체 설계는 문법 암기가 아니라 데이터 의미를 타입에 고정하는 과정입니다.