~sebsite added harec 1 year, 5 months ago

~sebsite added spec 1 year, 5 months ago

~sebsite added bug 1 year, 5 months ago

~sebsite 1 year, 4 months ago

Hm, I'm not actually sure if this is a good idea.

There isn't any technical reason why this should be disallowed, since constants are just substituted with their value. The actual justification for this (at least as I see it) is so tools like haredoc don't expose unexported declarations within the type.

The lack of a technical justification makes this less compelling though, especially with constant declarations being allowed as expressions:

fn f() void = {
    let x = if (true) {
        def FOO = 4;
        yield [0...]: [FOO]int;
    } else void;
    x as [4]int;
};

The above code is currently allowed, as I think it should be. There's not really a good reason not to allow it. But if we allow this, then the consistent thing to do here would be to allow it within exported types as well.

~ecs 1 year, 4 months ago

yeah i'm also not convinced this is a good idea tbh

~sebsite 11 months ago

Any objections to closing this as WONT_FIX?

~ecs REPORTED WONT_FIX 11 months ago

~turminal 9 months ago*

This decision implies exported types may depend on nonexported types transitively through an expression:

type x = void;
export type y = [3: (size | x): size]uint;

I guess we're also fine with that? I'm asking because default values for optional parameters are another place where such things can pop up - so far we only had @offset and array length.

~sebsite 9 months ago

Hm, yeah, good point. I think that's fine? It's easier to allow it than not to, and it doesn't cause any problems, so I don't think it's worth disallowing.

Definitely gonna steal this example for my spec examples patch though lol