Skip to content
This repository has been archived by the owner on Aug 28, 2023. It is now read-only.

Redesign: Propose Implicit Casting of Mutable- to Immutable Types #14

Closed
romshark opened this issue Oct 1, 2018 · 0 comments
Closed
Assignees
Labels
problem A general logical problem
Milestone

Comments

@romshark
Copy link
Owner

romshark commented Oct 1, 2018

Explicit casting will make this proposal break backward-compatibility with existing Go 1.x code because some parts of the standard library could to be rewritten to actually make use of the new immutability feature, which would cause existing Go 1.x code fail compiling in a newer compiler version with immutable type support.

The built-in append function should, for example, be rewritten, to make use of the immutability feature, in the following way:

func append(slicе [] const Type, elems ...const Type) []Type

This is necessary to make append guarantee not touching any of the inputs excepts the given slice (but not the Type's inside the slice). But this would break all existing Go 1.x code, because it would then require explicit type casting:

v := []int {1, 2, 3}
// The "old" way of using append will stop working:
v = append(v, 4, 5) // Compile-time error

// The "new" way would be:
v = append(const(v), const(4), const(5)) // Compile-time error

Proposal Redesign

In order to avoid breaking backward-compatibility implicit casting must be proposed instead.

@romshark romshark added the problem A general logical problem label Oct 1, 2018
@romshark romshark added this to the Publication milestone Oct 1, 2018
@romshark romshark self-assigned this Oct 1, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
problem A general logical problem
Projects
None yet
Development

No branches or pull requests

1 participant