C #에는 부작용 확인 기능이 포함되어 있습니까?

C #에는 부작용 확인 기능이 포함되어 있습니까?

---

C #이 많은 병렬 프로그래밍 지원을 받고 있다는 것을 알고 있지만 AFAIK에는 여전히 부작용 확인을위한 구성이 없습니다.

C #이 이미 배치 되었기 때문에 이제 더 까다 롭다고 생각합니다. 그러나 이것을 넣을 계획이 있습니까? 아니면 F #이 부작용 확인을위한 구조가있는 유일한 .NET 언어입니까?

---

C # 언어는 아니지만 .NET 프레임 워크 일 수 있습니다.

.NET 4에 도입 된 계약 라이브러리 + 정적 분석 도구는 다음을 도입 할 수 있습니다.

Microsoft는 현재 .NET 3.5 프레임 워크 내에서 [불변] 및 [순수]를 사용하고 있습니다.

예를 들어 System.Core.dll에서 .NET 3.5 내부의 [Microsoft.Contracts.Immutable] 및 [Microsoft.Contracts.Pure]를 참조하십시오. 불행히도 그들은 내부적입니다. 그러나 Microsoft.Contracts. *는 대부분 Spec # 연구에서 탄생했으며 Spec #은 .NET 4.0의 일부가 될 계약 API로 접혀졌습니다.

우리는 이것의 결과를 볼 것입니다. 시험판 .NET 4.0 비트에 Contracts API의 [Pure] 또는 [Immutable]과 같은 API가 포함되어 있는지 확인하지 않았습니다. 그렇다면 정적 분석 도구가 컴파일러가 아니라 규칙을 적용하는 도구가 될 것이라고 생각합니다.

편집 이번 주 MS 코드 계약 의 최신 시험판 드롭 에서 Microsoft.Contracts.dll을로드 했습니다. 좋은 소식 : [Pure] 및 [Mutability (Mutability.Immutable)] 속성이 라이브러리에 존재하며 이는 .NET 4.0에있을 것임을 시사합니다. 우후!

편집 2 이제 .NET 4가 출시되었으므로 이러한 유형을 검색했습니다. [Pure] 는 여전히 System.Diagnostics.Contracts 네임 스페이스에 있습니다. 일반적인 사용을위한 것이 아니라 Contract API의 사전 및 사후 조건 확인과 함께 사용하기위한 것입니다. 컴파일러가 적용 되지 않으며 코드 계약 검사기 도구도 순도를 적용하지 않습니다 . [Mutability]가 사라졌습니다. 흥미롭게도 Microsoft가 .NET 3.5 (System.Core.dll의 내부 BigInteger 클래스에서)에서 Mutability 및 Pure 속성을 사용하던 곳에서 .NET 4는 BigInteger를 System.Numerics로 이동하고 [Pure] 및 [Mutability]를 제거했습니다. 그 유형의 속성. 결론 : .NET 4는 부작용 확인을 위해 아무것도하지 않는 것 같습니다.

편집 3 최근 (2011 년 말) 미리보기 된 Microsoft Rosyln 서비스로서의 컴파일러 도구 (Visual Studio 2015에서 RTM 용으로 예정된 것으로 추정 됨)를 사용하면 이러한 도구를 지원할 수있을 것 같습니다. 순도와 불변성을 확인하기 위해 컴파일러에 대한 확장을 작성하고 해당 속성으로 장식 된 것이 규칙을 따르지 않는 경우 컴파일러 경고를 발행 할 수 있습니다. 그럼에도 불구하고 우리는 이것을 지원하기 위해 몇 년을 기다리고 있습니다.

edit 4 이제 Rosyln이 2015 년 여름부터 여기에 왔으므로 순수 / 불변성을위한 컴파일러 확장을 빌드하는 기능이 실제로 존재합니다. 그러나 기존 프레임 워크 코드 나 타사 라이브러리 코드에 대해서는 아무 작업도 수행하지 않습니다. 그러나 곧 불변 유형에 대한 C # 7 제안이 있습니다 . 이것은 컴파일러에 의해 시행되며 C #에 새로운 불변 키워드와 .NET 프레임 워크의 [Immutable] 특성을 도입합니다. 용법:

// Edit #4: This is a proposed design for C# 7 immutable as of June 2015.
// Compiler will implicitly mark all fields as readonly.
// Compiler will enforce all fields must be immutable types.
public immutable class Person
{
    public Person(string firstName, string lastName, DateTimeOffset birthDay)
    {
        FirstName = firstName; // Properties can be assigned only in the constructor.
        LastName = lastName;
        BirthDay = birthDay; 
    }

    public string FirstName { get; } // String is [Immutable], so OK to have as a readonly property
    public string LastName { get; }
    public DateTime BirthDay { get; } // Date is [Immutable] too.
}

edit 5 2016 년 11 월이고 C # 7에서 변경 불가능한 유형이 삭제 된 것으로 보입니다. 항상 C # 8에 대한 희망이 있습니다. :-)

edit 6 2017 년 11 월입니다. C # 8이 전체보기로 나옵니다. 순수 함수는 없지만 readonly structs 를 갖게됩니다 . 이는 구조체를 불변으로 만들어 여러 컴파일러 최적화를 허용합니다.

---

부작용 검증을위한 것이 없을뿐만 아니라 유형이 변경 불가능한지 검증 할 것도 없습니다. 이는 동일한 경로 IMO를 따라 더 작은 단계입니다.

나는 C # 4.0에서 파이프 아래로 내려 오는 것이 있다고 생각하지 않습니다 (쉽게 틀릴 수 있지만). 저는 불변성이 C # 5.0에 영향을 미치기를 정말로 바랍니다 . 확실히 Eric Lippert는 그것에 대해 꽤 많은 블로그를 올렸고 MS의 사람들은 병렬 처리에 대해 상당한 양을 생각했습니다.

더 고무적인 사진이 아니 어서 죄송합니다.

편집 : 유다의 대답 은 상당히 밝습니다 ... 프레임 워크 지원이 당신에게 충분할까요? :) (코드 계약의 일부 측면이 .NET 4.0에 대해 준비되지 않았다고해도 놀라지 않을 것입니다. 초기 릴리스를 상대적으로 작게 유지하고 나중에 강화 했다면 유의하십시오 .)

---

원칙적으로 어떤 것이 불변인지, 코드에 부작용이 없는지 확인하는 것은 쉽습니다. 클래스 / 데이터 구조의 모든 필드는 읽기 전용이어야하며 해당 유형은 다른 불변 객체 여야합니다. 또한 델리게이트를 "순수"(부작용이 없음)로 표시하는 방법이 필요하지만 그게 모두 가능할 것입니다.

그러나 문제는 이것이 종종 너무 제한적이라는 것입니다. F #에서는 일반적으로 부작용이없고 변경할 수없는 스타일로 코드를 작성하지만 로컬에서 일부 변형을 사용하는 것이 유용한 경우가 많습니다. 이것은 전체적인 순도 (어떤 의미에서)를 깨뜨리지 않으며 코드 작성을 훨씬 쉽게 만듭니다. 그러나이를 자동으로 확인하는 것은 어렵다 (흥미로운 이론적 문제라는 의미).

예를 들어, "순수한"방식으로 배열 작업을하는 것은 완벽합니다. 모든 요소에 일부 함수를 적용 하고 원래 배열을 수정하지 않고 새 배열을 반환하는 Array.map 과 같은 메서드를 가질 수 있습니다 . 이 함수는 (새로 생성 된) 배열을 반환하기 전에 변경하지만 배열은 다른 곳에서는 변경되지 않으므로 원칙적으로 순수 하지만 확인하기가 어렵습니다 (그리고 이것은 F #에서 매우 유용한 프로그래밍 패턴입니다).

그래서 저는 할 수있는 일이 많이 있다고 생각하지만 단순히 모든 부작용을 금지하는 것은 보이는 것처럼 좋은 방법이 아닐 수 있습니다. 계약의 좋은 점은 계약이이 시나리오에서도 사용될 수 있다는 것입니다.

참고URL : https://stackoverflow.com/questions/592934/does-or-will-c-sharp-include-features-for-side-effects-verification