Hacker News 의견

• C#와 Kotlin의 null 처리 방식 비교

  • C#은 프로젝트에서 nullability를 활성화하면 모든 변수가 기본적으로 non-null로 선언됨
  • Kotlin도 비슷하지만, backwards compatibility가 필요하지 않음
  • Kotlin은 lateinit var 선언을 통해 초기화되지 않은 non-nullable 변수를 나중에 초기화할 수 있는 기능을 제공함

• 새로운 제안에 대한 의견

  • 기존 변수들이 nullable, explicitly nullable, explicitly non-nullable로 구분됨
  • C#의 접근 방식이 더 나아 보임, 특히 레거시 코드베이스에서 nullability 문제를 해결할 필요가 없음
  • 그러나 C# 접근 방식은 코드베이스에서 nullability 문제를 즉시 강조함

• nullness-narrowing 자동 변환에 대한 우려

  • 자동 변환이 잘못된 느낌을 줌
  • 컴파일러 오류를 발생시켜야 할 경우가 있음
  • 명시적인 변환이 더 안전함

• 모든 변수를 기본적으로 non-null로 표시하는 방법 필요성

  • 패키지나 파일 수준에서 모든 변수를 non-null로 표시할 수 있는 방법이 필요함
  • 그렇지 않으면 T! 구문을 거의 모든 변수에 사용하게 되어 코드가 복잡해짐

• Java에서 언어 수준의 명시적 optionality 기능 필요성

  • Kotlin과 Typescript에서의 경험을 바탕으로 언어 수준의 지원이 더 나음
  • Java의 NullAway 같은 도구는 번거로움

• 표준 라이브러리에 언어 개선 사항을 적용하지 않는 결정에 대한 비판

  • PHP 사용 경험에서 표준 라이브러리와의 상호작용이 번거로움
  • 표준 라이브러리에 이러한 표현력을 추가하는 것이 필요함

• 컴파일 타임 경고를 오류로 승격하는 쉬운 방법 필요성

  • Java는 주로 정적 타입 언어이므로 동적 동작을 도입하는 것은 좋지 않음

• 기본적으로 non-nullable, immutable, 좁은 범위로 설정해야 하는 필요성

  • 새로운 디자인 결정이 즉각적인 편의성을 위해 안전한 경로를 포기하는 경우가 많음
  • 많은 언어와 기술에서 이러한 문제로 인해 많은 오류가 발생함

• Hack 언어에서의 null 처리 경험

  • Hack의 타입 시스템에서 nullness가 중요한 부분임
  • nullable 배열에 대한 질문
  • Java에서는 모든 레거시 코드가 nullability를 가정하므로 문제가 됨

• Java SDK에 이 기능을 적용할 수 있는지에 대한 질문

  • 레거시 코드에 대해 어떻게 적용할 수 있을지에 대한 의문

• 관련 링크 제공

  • NullAway
  • Hack의 nullable 타입 문서
  • JEP 링크