이게 어떻게 통과하나요?
const std = @import("std");
pub fn main() !void {
const outcome =
std.debug.print("Hello, world\n", .{});
_ = outcome;
}std.debug.print()의 결과는 void인데, 그 결과를 outcome에 넣어도 Zig는 아무 말도 하지 않네요.
프로젝트를 하다가 외부 라이브러리의 API가 값을 반환한다고 착각해서 이 문제를 만났어요. 결국 {s}로 그 결과를 문자열에 포맷하려니 컴파일러 오류가 났지만, 처음의 잘못된 가정까지 거슬러 올라가는 데 시간이 걸렸어요.
void를 변수에 저장하는 게 유용한 경우도 있나요?
How is this accepted?
const std = @import("std");
pub fn main() !void {
const outcome =
std.debug.print("Hello, world\n", .{});
_ = outcome;
}The result of std.debug.print() is void, yet binding that result to outcome produces no complaint from Zig.
I encountered this while working on a project, after incorrectly thinking an API from a third-party library produced a value when it actually didn't. Eventually, formatting that result as a string using {s} caused a compiler error, though tracing it back to my initial assumption took some time.
When would storing void in a variable be helpful?
값이 존재할지 자체를 comptime에 정하는 코드를 더 단순하게 해 줍니다.
함수 타입을 분석하며 여러 겹의 오류 유니온을 따라가는 것보다, 결과를 담은 변수의 타입을 확인하는 편이 훨씬 쉽고 여기서 유용합니다.
다른 작업도 하는 함수라면 어차피 호출해야 할 수도 있고요.
그 밖에는 쓸모없는 값을 허용한다고 크게 해로울 건 없습니다.
It simplifies code in which comptime decides whether there is a value at all.
Rather than picking apart a function's type, potentially through several error unions, checking the type of its bound result is much simpler, and thats useful here.
You may also need the call to happen anyway because it performs other work.
Allowing a value with no other use doesn't cause much trouble.
이 정보는 반드시 존재해야 하는 게 아닙니다. 어떤 표현식은 이런 정보를 전혀 제공하지 않으니까요. 예를 들어 _에 대입하는 것은 표현식의 타입을 알려 주지도, 그 결과를 둘 구체적인 메모리 위치를 제공하지도 않습니다.
Result Location Semantic (https://ziglang.org/documentation/master/#Result-Location-Semantics)
This information needn't always exist, because certain expressions provide no such information at all: assigning to _, for example, tells you nothing about an expression's type and supplies no particular place in memory where its result belongs.
Result Location Semantic (https://ziglang.org/documentation/master/#Result-Location-Semantics)
어떤 항목을 언제 test 블록 안에서 “버려야” 하는지 궁금합니다. 예를 들어 std.zig 모듈 소스 끝에는 이런 코드가 있어요:
test {
_ = Ast;
_ = AstRlAnnotate;
_ = BuiltinFn;
_ = Client;
_ = ErrorBundle;
_ = LibCDirs;
_ = LibCInstallation;
_ = Server;
_ = TokenSmith;
_ = WindowsSdk;
_ = number_literal;
_ = primitives;
_ = string_literal;
_ = system;
_ = target;
_ = c_translation;
_ = llvm;
_ = @import("zig/parser_fuzz.zig");
}라이브러리라면 가져온 모듈을 전부 저기에 넣어야 하나요? 아니라면 어떤 모듈에 이 처리가 필요한가요?
I'm wondering which items need “discard”-ing inside a test block, and when? As an example, the end of the std.zig module's source contains this:
test {
_ = Ast;
_ = AstRlAnnotate;
_ = BuiltinFn;
_ = Client;
_ = ErrorBundle;
_ = LibCDirs;
_ = LibCInstallation;
_ = Server;
_ = TokenSmith;
_ = WindowsSdk;
_ = number_literal;
_ = primitives;
_ = string_literal;
_ = system;
_ = target;
_ = c_translation;
_ = llvm;
_ = @import("zig/parser_fuzz.zig");
}For a library, should every module I import go there? Otherwise, which modules need this treatment?
라이브러리라면 가져온 모듈을 전부 저기에 넣어야 하나요? 아니라면 어떤 모듈에 이 처리가 필요한가요?
루트 파일의 테스트만 암묵적으로 실행되므로, 다른 파일/모듈/네임스페이스는 테스트를 담은 네임스페이스를 참조해야 합니다. 루트 파일 안에서도 테스트를 담은 struct/union/enum에는 마찬가지로 각각 참조가 필요합니다.
분명히 하자면, sample.member는 sample.member만 참조하고 sample는 참조하지 않지만, _ = sample는 sample 자체를 참조합니다.
For a library, should every module I import go there? Otherwise, which modules need this treatment?
Tests run implicitly for the root file alone, so with other files/modules/namespaces, the namespace containing those tests must be referenced. That also applies to a struct/union/enum containing tests inside the root file, each needs a reference as well.
For clarity, mentioning sample.member references only sample.member, not sample, while _ = sample references sample itself.
안녕하세요, 제가 코드를 바꿀 수 없는 패키지에 다음과 같은 클래스 계층이 있어요: 편하게 쓰려고 Inner를 감싸는 래퍼를 추가하려는데, Inner가 바깥 인스턴스에 의존해서 지금까지는 바깥 클래스의 서브클래스 안에 넣는…
아래 두 표현식을 보니 그리고 똑같이 동작하더군요. 정리를 증명할 때도 마찬가지예요. 서로 바꿔 써도 되나요? 차이가 뭔가요?
각 항목이 문자열 배열을 담는 Map을 만들고 있어요. 타입 선언과 초기화를 한 문장으로 같이 하려면 어떻게 하나요? 제 (단순한) 시도는 이랬어요: 그랬더니 이렇게 나와요:
