Go의 Generics에 맞는 라이브러리를 만들어 봤습니다.

다음 달 발매 예정인 Go1.18부터 Generics가 대응해 함수 정의에서 다양한 유형의 처리를 맡을 수 있다.
현재 베타 버전에서는 다양한 사람들이 다양한 사용법을 시도하고 있다고 생각하지만, 가까스로 이 기회에Generics에 대응하는 프로그램 라이브러리(pre)를 만들어 공개해 봤기 때문이다.
그리고 어렵기 때문에 Generics 환경을 실제로 접한 소감도 함께 써보고 싶어요.
주의 사항
이 기사는 2022년 1월 당시 현황을 토대로 기재됐다.
2월에 정식으로 고1.18 발표 후 일부 상황이 바뀔 수 있습니다.
작성된 라이브러리
Map과 Filter 등 다른 언어에서 흔히 볼 수 있는 Collection을 조작하는 처리의 조합입니다.
내부는 합성 Iterator의 실제 설치를 통해 가능한 한 간단하게 Collection 쓰기 처리의 합성을 할 수 있다.
현재는 슬라이스나 Repeat 함수로 같은 요소를 배열해 콜렉션 원본을 만들 수밖에 없지만, 앞으로는 채널에서 원본을 만들고 함수로 기본 요소를 만드는 것을 고려할 계획이다.
README에 어떤 기능을 사용할 수 있는지 대략적으로 적혀 있으니 한번 보세요.
주로 일본어판을 쓰니까 이게 더 이해가 가는 것 같아요.
왜 그랬어
'go'의 기능 설정은 간단하지만 이전에 사용했던 언어에서 하나하나 연쇄되어 이루어진 것을 처리하려면 기본적으로 for,if 등 기본 구조를 조립하여 써야 한다.
goo계 일대로서 이런 문법은 예의적인 것이기 때문에 돈을 벌고 싶을 때 이렇게 해야 하지만 논리적으로 엄격한 연기 요구가 없을 때도 이렇게 쓰는 것이 번거롭다고 느낀다.(내 경우)
이전에 자주 사용했던 C#에서 Linq가 대표적인 예입니다, goo1.17까지 만들려면 go generate에서 유형별로 함수를 준비하는 건지 요소interface{}로 처리하는 건지 둘 다 관계가 크다고 생각해요.
그래서 Generics는 어느 정도 유니버설 로봇을 사용할 수 있었고 몇 차례의 버전 업그레이드와 동시에 드디어 발매 목표가 생겼고 베타가 나온 후에 당시의 기세로 코드를 한꺼번에 썼다.
간단히 말해서 Generics의 이 기능을 터치하고 싶어서 만든 것(*´)ω`*)
간단한 사용법
doc 리뷰나 Example도 쓰지만 아래에 내선 설명을 넣어 간단하게 사용하세요.

import (
    fmt
    github.com/meian/gcf
)


// スライスからコレクション(Iterable)を作成する
// データソースの作成以外はこのコレクションを引き回して処理を組み立てることになる
itb := gcf.FromSlice([]string{"hoge", "foo", "bar"})

// 関数の条件に一致する要素のみを抽出
itb = gcf.Filter(itb, func(v string) bool {
    return len(v) == 3
})

// コレクションを2回繰り返す
itb = gcf.RepeatIterable(itb, 2)

// 処理した結果をスライスで取得する
s := gcf.ToSlice(itb)

fmt.Println(s)
// Output:
// [bar foo bar foo]

감상
※ 본문의 주요 내용은 여기
제작, 현황에 대한 개발 환경 등등.
방법으로 유형의 툴라미를 지정할 수 없습니다
Go1.18의 Generics에 관한 툴라미.
이걸 느낀 사람이 많을 텐데, 이번에 추가된 Generics type parameter

type을 통해 지정한 형식 인터페이스(not alias)

func의 최고급 함수 정의

그중에 하나만 넣을 수 있죠?
그러면 현재 실시되고 있는 것은 Map뿐입니다. 만약에 원래 소장과 처리된 소장 유형이 변했다면 struct or 인터페이스의 방법으로 그것들을 정의할 수 없습니다.
(이것이 있기 때문에 gcf에서 방법체인은 곧 포기했고 모두 함수로 실현되었다)
프로펠러를 잘 쫓지는 않지만, 그동안 type parameter의 지원을 받았으면 좋겠습니다.
애매모호하다
Generics 정의 처리를 사용하는 측면에 대한 추론
제작을 시작하기 전에 함수가 어느 정도까지 은근히 추론될지 불안하죠.
특히 맵 같은 처리 함수의 결과형은 기존 컬렉션과 관련이 없으니 주워주겠나.
단지 실제적으로 해봤을 때 라이브러리 안에 [T]라고 대량으로 쓰여 있었지만 사용방면(test와 example)은 기본적으로 명확한 표현 형식을 필요로 하지 않고 파라미터의 내용에서 유형을 잘 판단해서 탄복했다.
LSP(gopls) 보완
vscode에서 Language Server의 대응 상황 정보
vscode를 통해 함수의 매개 변수에 함수를 전달하는 경우 입력 후보에서func를 선택하면 매개 변수로 확장할 수 있습니다.

이걸 펼치면 이렇게 되겠지.

나는 모든 것이 추론 형식으로 전개될 수 없다는 것을 알고 있지만, 여기는 이미 앞의 매개 변수에서 해결된 유형이기 때문에 int로서...
CI 아직 작동 안 함
GiitHub의 운용 체제에 관하여
있어요, 없어요, 그래서 소스를 확인했는데 setup-go의 대응이 1.17.6도 안 돼서 Giithub Actions는 아직 사용할 수 없습니다.
엄밀히 말하면 18-rc의 스크립트를 떨어뜨려 설치하면 완성할 수 없는 것도 아니지만 다운로드할 때마다 너무 느리고 setup-go처럼 독립적으로 설치된 캐시도 너무 쓸모없기 때문에 저는 여기서 GA를 가만히 기다리고 있겠습니다.
그 전에 로컬 수동 테스트의 수동 덮어쓰기 검사였죠.(:3」∠)_
pkg.go.dev반응도 아직 안 끝났어?
doc 평론 공개에 관하여.
나는 부탁을 해 보았는데, 결과적으로 not found라고 불렸다.
같은 계정에 다른 Goo 도구가 게재되어 있기 때문에Generics에 대응하는 창고를 분석할 수 없습니다.
여기도 기다릴 수밖에 없을 것 같습니다.
로컬go tool doc에서 1.18-rc의 인상에서 이동하지만, goodoc는 어떻습니까?
프로그램 라이브러리의 사용이 편리하다
아직 자체적으로 이걸로 앱을 만들지 않았기 때문에 (정말 기세로 만들었다) 명확하게 말할 수 없고, 아마 아래에서 준비하지 않으면 고오가 힘들 것 같다.
그리고 CI 없이 v01.0 자르는 것도 좀 그렇다. 빨리 GA가 됐으면 좋겠다.
error의 대응
goo의 오류 처리는 error 대상을 발생원에서 처리 목적지로 끌어올려서 이루어진 것이기 때문에 함수나 방법의 반환값(T, error)으로 자주 사용된다.
따라서 Filter,Map 등의 함수를 통해 처리하는 기능은 FilterE,MapE 등 오류를 회신할 수 있는 형식이 형성되지 않으면 사용 범위가 줄어든다.
(혹은 빨리 하자고)
최후
모처럼의 기회이기 때문에 기능 요구나 이 제작 방법의 변화 같은 피드백을 받을 수 있다면 감사하겠습니다.
그리고 완전 개인게임이라 관객이 없어서 부탁할 수 있는 사람, 아니면 여기서 해서 홍보하고 싶은 사람, 이런 사람을 잡아주시면 너무 감사합니다(*´)ω`*)