Updating list-ops test generic types parameters

[Shoghy]

I added and deleted generic type parameters from the list-ops exercise tests.

I did this because I was having problems compiling the code and I also noticed that several generic types were redudant, considering that the List class has a generic type like Array.

I will list 2 of the changed tests and the reasons why I added or removed the generic type parameter, the other tests were changed for the same reasons:

/*...*/
xit('list to empty list', () => {
  const list1 = List.create<number>()
  const list2 = List.create(1, 2, 3, 4)
  expect(list1.append(list2)).toEqual(list2)
})
/*...*/

In this first test I added the generic type parameter <number> to list1 so that, even though the constant list1 has no elements, TypeScript understands that it stores the same type value as list2. I did not add <number> to list2 because the type of value it stores is automatically deduced by the parameters sent in the create function.

---

/*...*/
describe('filter list returning only values that satisfy the filter function', () => {
  xit('empty list', () => {
    const list1 = List.create<number>()
    expect(list1.filter((el) => el % 2 === 1)).toHaveValues()
  })
/*...*/

In this case I understand that <number> in filter refers to the type of value that the list returned by filter will store, however this is not necessary if List has a generic type, since the returned list will store the same type of value as the original list.

[github-actions]

Hello. Thanks for opening a PR on Exercism 🙂

We ask that all changes to Exercism are discussed on our Community Forum before being opened on GitHub. To enforce this, we automatically close all PRs that are submitted. That doesn't mean your PR is rejected but that we want the initial discussion about it to happen on our forum where a wide range of key contributors across the Exercism ecosystem can weigh in.

You can use this link to copy this into a new topic on the forum. If we decide the PR is appropriate, we'll reopen it and continue with it, so please don't delete your local branch.

If you're interested in learning more about this auto-responder, please read this blog post.

---

Note: If this PR has been pre-approved, please link back to this PR on the forum thread and a maintainer or staff member will reopen it.

[Shoghy]

@SleeplessByte

[SleeplessByte]

@Shoghy I have rebased this for you. You must also update proof.ci.ts in .meta, for the linter to be satisfied. Can you make that change? You'll then want to check the linter.

[Shoghy]

@Shoghy I have rebased this for you. You must also update proof.ci.ts in .meta, for the linter to be satisfied. Can you make that change? You'll then want to check the linter.

How do I test that file so I can be sure my changes are all right?

[SleeplessByte]

@Shoghy from CONTRIBUTING.md

If the ASSIGNMENT environment variable is set, only that exercise is tested. For example, if you only want to test the example.js for two-fer, you may, depending on your environment, use:

ASSIGNMENT=practice/two-fer corepack yarn test

So in your case it would be

ASSIGNMENT=practice/list-ops corepack yarn test

or if you are on windows

corepack yarn dlx cross-env ASSIGNMENT=practice/two-fer corepack yarn test

[SleeplessByte]

I'll reformat the file now:

/format

[github-actions]

The "Format code" action has started running.

[SleeplessByte]

Why is this necessary? Doesn't new Cons(item, this) already infer Const<T>? If not, shouldn't it be new Cons<T>(item, this)?

[Shoghy]

In this case Cons would be of type Cons<T | undefined>, however because of how Null works the undefined part can be omitted, and since is of type Cons<T | undefined> using new Cons<T>(item, this) throws an error on TypeScript.

[SleeplessByte]

It's probably better to define it as:

public next: Cons<T> | Cons<undefined>

instead of needing the as Cons<T>

[Shoghy]

This can make the code a little bit messier with the types, and the only method where this is important is get, so that's why I made the return value of get be T | undefined

[SleeplessByte]

I think overall it's a net improvement (less explicit types in the tests), but I am not completely convinced about the proof solution. However let's get this merged and make further improvements in future PRs

Thank you for working on this!