[WIP] seq[T] as regular library code

[timotheecour]

This is an experiment / proof of concept to see whether seq[T] could be turned into a regular library code without special compiler support, which would simplify lots of things in the compiler if that were the case, as well as remove edge cases (eg #13303 (comment) among many others).

many things work but some things don't:

what works

  proc main() =
    var a = @[10,11]
    a.add 12
    doAssert $a == "@[10, 11, 12]"
    doAssert type(a) is seq[int]
    doAssert type(a) is seq
    var a2 = default(type(a))
    for ai in a:
      a2.add ai*10
    doAssert a2 == @[100, 110, 120]
    var a3 = newSeq[int](1)
    doAssert a3 == @[0]
    a3.add 17
    a3.newSeq(4)
    doAssert a3 == @[0, 17, 0, 0]
    var a4 = @["foo"] & @["bar"]
    a4[0] = "FOO"
    a4[1].add "t"
    doAssert a4 == @["FOO", "bart"]
    a4 = @[]
    doAssert a4.len == 0

what doesn't work

• conversion to openArray from seq
  I tried this but it didn't work:

converter toOpenArray2*[T](a: var seq[T]): var openArray[T] = toOpenArray(a, 0, len(a)-1)

this could be fixed by making OpenArray first class, eg see nim-lang/RFCs#88; or using a compiler patch

• var s: seq[int] = @[]
  this one is easily fixed, can be fixed using same hack as I did to support:

var s: seq[int]
s = @[] # this already works

• seq at CT
  const a = @[1,2] gives: system/gc.nim(103, 24) Error: cannot evaluate at compile time: gch

TODO

• consider what to do with macros.tySeq

links

(EDIT)

• see tests/destructor/tcustomseqs.nim which looks like it attempted something similar

[cooldome]

Problems that you will encounter are const seq and seq in vm.

Possibly, there is generic solution that can make any container that allocates dynamic memory VM and const compatible. Once such solution found and implemented, it will be possible to make seq a library

[krux02]

Well, there is still this tySeq from macros that you will break for sure. But generally like this Idea.

[Araq]

Stalled PR, good idea, but const sections are an open problem and the reason why the destructor based new seqs are still builtin for the time being.

[timotheecour]

just noticed tests/destructor/tcustomseqs.nim which might've been an attempt at doing the same thing