type vhost* = object
name* : string
port* : int = 8000
host : string
ipaddr : seq
why this is not allowed ?
Maybe read linked comments? https://github.com/nim-lang/RFCs/issues/126#issuecomment-615014367
block:
type R = range[10..13]
doAssert R.default == 0 # broken
var a: R
doAssert a == 0 # broken
type Foo = enum k1 = 10, k2 # not even enum with holes
var b: Foo
doAssert b.ord == 0 # broken
doAssert $b == "0 (invalid data!)" # broken
## affects any type that has a (sub-) member with non-valid-default
type Bar = object
a1: Foo
a2: R
# var c: Bar # this doesn't even compile
var c = default(Bar) # that does compile, but still broken
doAssert $c == "(a1: 0 (invalid data!), a2: 0)"
large portion of type safety guarantees is invalidated - enum with offset, ranges now can't really guarantee anything unless explicitly created with initT. Any kind of value that has non-zero default requires special attention - it is now your responsibility to make sure this -1-as-default-value is actually used. {.requiresinit.} is a solution, but has already mentioned it propagates through whole codebase, requiring far-reaching modifications.
Any other alternative to types?
No, there are no alternatives to types of course
So those mentions bugs still exist?
Those are not bugs, that's how language was originally designed to be. I would also prefer to have a notion of constructor in the language, instead of having several different styles of initialization, but for now you are supposed to write initVHost proc that creates an object for you.
instead of having several different styles of initialization
You always have these different styles anyway, C++'s super elaborate way of doing construction with all its power could not avoid make_shared.
bare with me i am new to nim and static typing so wondering if nim is ok with those broken type systems.
Just because somebody called it "broken" that doesn't make it true...
It's still usable, there are just sections that are "broken"
It is not fully broken, but there are some parts that don't work as one might expect. They are related the original question, so that's why they were brought up. All linked issues/comments/RFC talk about this specific part.
there are some parts that don't work as one might expect
ALL parts don't work as SOMEONE might expect.