C#의 순수 함수들

Question

C#이 많은 병렬 프로그래밍 지원을 받고 있음을 알고 있지만 AFAIK는 여전히 부작용 검증을위한 구성 요소가 없습니다.

C#이 이미 배치 된 지금은 더 힘들다고 가정합니다. 그러나 이것을 얻을 계획이 있습니까? 또는 F #은 부작용 검증을위한 구조를 가진 유일한 .NET 언어입니까?

Answer 1

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

컨 라이브러리 + 정적 분석 도구는 다음을 소개 할 수 .NET 4에서 도입 :

마이크로 소프트는 현재 .NET 3.5 프레임 워크 내에서 [순수]를 사용하여 [불변]된다.

예를 들어, .NET 3.5의 System.Core.dll에서 [Microsoft.Contracts.Immutable] 및 [Microsoft.Contracts.Pure]를 참조하십시오. 불행히도, 그들은 내부적입니다. 그러나 Microsoft.Contracts. *는 대부분 SpeC# 연구에서 만들어졌으며 SpeC#은 .NET 4.0에 포함될 계약 API로 변환되었습니다.

우리는이 부분을 보게 될 것입니다. 시험판 .NET 4.0 비트에 [순수] 또는 [변경 불가능]과 같은 API가 계약 API에 포함되어 있는지 확인하지 않았습니다. 그렇다면 정적 분석 도구가 컴파일러가 아닌 규칙을 시행하는 도구가 될 것이라고 생각합니다.

편집 이번 주에 latest pre-release drop of MS Code Contracts에서 Microsoft.Contracts.dll을로드했습니다. 좋은 소식 : 라이브러리에 [Pure] 및 [Mutability (Mutability.Immutable)] 속성이있어 .NET 4.0에 포함될 것임을 알 수 있습니다. 우!

편집 2 이제 .NET 4가 출시되었습니다.이 유형을 찾았습니다. [Pure]은 여전히 ​​System.Diagnostics.Contracts 네임 스페이스에 있습니다. 일반적인 용도가 아닌 Contract API의 사전 및 사후 조건 확인에 사용하기위한 것입니다. 컴파일러가 적용되지 않습니다 (neither does the Code Contract checker tool enforce purity). [돌연변이]가 없어졌습니다. 흥미롭게도 Microsoft가 System.Core.dll의 내부 BigInteger 클래스에서 .NET 3.5에서 Mutability and Pure 특성을 사용하는 경우 .NET 4는 BigInteger를 System.Numerics로 옮겼으며 [순수] 및 [Mutability] 해당 유형의 속성. 결론 : .NET 4는 부작용 검증을 위해 아무 것도하지 않습니다.

편집 최근 (2011 말)와 3 마이크로 소프트 Rosyln 컴파일러 서비스로서의 도구를 미리 - 비주얼 스튜디오 2015 년 RTM 예정 것으로 추정 - 그들이 지원 할 수 있습니다처럼 이런 물건. 순도와 불변성을 검사하기 위해 컴파일러에 확장 기능을 작성하고 이러한 속성으로 꾸며진 것이 규칙을 따르지 않으면 컴파일러 경고를 발행 할 수 있습니다. 그럼에도 불구하고 우리는 이것을 지원하기 위해 몇 년을 기다리고 있습니다.

편집 4 이제 Rosyln은 2015 년 여름부터 pure/immutability를위한 컴파일러 확장을 빌드하는 기능이 실제로 존재합니다. 그러나 기존 프레임 워크 코드 나 제 3 자 라이브러리 코드에는 아무런 영향을 미치지 않습니다. 그러나 수평선에 C# 7 proposal for immutable types입니다. 이것은 컴파일러에 의해 시행되고 새로운 불변의 키워드를 C# 및 .NET 프레임 워크의 [변경 가능] 특성으로 도입합니다. 사용법 :

// 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. 
} 

편집 5 그것은 11 월 (2016), 그리고 불변의 종류 C# 8. :-)

편집 6 그것은 11 월 2017 년입니다 항상 희망이있어 C# 7.에서 제외되었다가 나타납니다. C# 8이 전체적으로 보입니다. 순수한 기능은 없지만 readonly structs이됩니다. 이로 인해 구조체가 변경되지 않아 여러 컴파일러 최적화가 가능합니다.

Answer 2

부작용 검증을위한 것만이 아니라 형식이 변경 불가능하다는 것을 확인할 필요도 없습니다. 동일한 경로 IMO에서 더 작은 단계입니다.

나는 C# 4.0에서 파이프가 내려오고 있다고 생각하지 않습니다 (쉽게 틀릴 수도 있지만). 나는 정말로 불변성이 C# 5.0에서 영향을 줄 것을 희망한다. 확실히 에릭 리 퍼트 (Eric Lippert)는 블로그에 대해 꽤 많이 블로그에 올랐으며, MS의 사람들은 평행주의에 대해 상당한 양의 생각을 해왔습니다.

죄송합니다. 더 이상 유감스럽지 않은 그림입니다.

편집 : Judah's answer은 상당히 밝습니다 ... 프레임 워크가 충분히 도움이됩니까? :) (아마도 초기 계약을 으로 유지하고 나중에을 작게하고 부스트하면 코드 계약의 일부 측면이 .NET 4.0에 대한 준비가되지 않았다면 완전히 놀라지 않을 것입니다.)

Answer 3

기본적으로 코드에 부작용이 없는지 여부를 확인하기 위해 어떤 것이 불변인지 여부를 확인하는 것이 쉽습니다. & 클래스/데이터 구조의 모든 필드는 읽기 전용이어야하며 유형은 다른 불변 객체 여야합니다. 우리는 또한 대의원을 "순수한"(부작용이없는) 것으로 표시하는 방법이 필요하지만, 아마도 그렇게 할 수 있습니다.

그러나 문제는 너무 제한적이라는 것입니다. F #에서는 일반적으로 부작용이없는 코드를 & 불변 스타일로 작성하지만 로컬에서 일부 변형을 사용하는 것이 종종 도움이됩니다. 이것은 전반적인 순도를 손상시키지 않으며 (일부 의미에서) 코드를 작성하는 것이 훨씬 쉬워집니다. 그러나 이것을 자동으로 확인하는 것은 어렵습니다 (흥미로운 이론적 인 문제를 의미 함).

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

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