ListAssembler.ValueStyle does need a parameter.

It needs this for dealing with the exciting details of...
well, you can read the comment.

This is a heck of an example of how the schema system, even though
we've been almost completely successful in isolating it in packages
and not letting it appear or be referenced in any of the core
interfaces and main dependencies... is still informing and shaping
a few key details of the central interfaces.

Future IPLD library implementers in other languages may want to take
note of this commit for the above reason: it's useful to make sure
you've also taken account of schema systems in your library design
at an early point.  Even if you don't intend to implement them before
doing a 1.0 of the core interfaces and Data Model essentials,
knowing what expressiveness will be needed will save you a lot of work.

fluent/fluentBuilder.go

@@ -72,7 +72,7 @@ type MapAssembler interface {
 type ListAssembler interface {
 	AssembleValue() NodeAssembler
 
-	ValueStyle() ipld.NodeStyle
+	ValueStyle(idx int) ipld.NodeStyle
 }
 
 type nodeAssembler struct {
@@ -174,6 +174,6 @@ type listNodeAssembler struct {
 func (fla *listNodeAssembler) AssembleValue() NodeAssembler {
 	return &nodeAssembler{fla.la.AssembleValue()}
 }
-func (fla *listNodeAssembler) ValueStyle() ipld.NodeStyle {
-	return fla.la.ValueStyle()
+func (fla *listNodeAssembler) ValueStyle(idx int) ipld.NodeStyle {
+	return fla.la.ValueStyle(idx)
 }

node/basic/list.go

@@ -217,7 +217,7 @@ func (la *plainList__Assembler) Finish() error {
 	// validators could run and report errors promptly, if this type had any.
 	return nil
 }
-func (plainList__Assembler) ValueStyle() ipld.NodeStyle {
+func (plainList__Assembler) ValueStyle(_ int) ipld.NodeStyle {
 	return Style__Any{}
 }
 
@@ -320,7 +320,7 @@ type plainList__ValueAssemblerList struct {
 func (la *plainList__ValueAssemblerList) AssembleValue() ipld.NodeAssembler {
 	return la.ca.AssembleValue()
 }
-func (plainList__ValueAssemblerList) ValueStyle() ipld.NodeStyle {
+func (plainList__ValueAssemblerList) ValueStyle(_ int) ipld.NodeStyle {
 	return Style__Any{}
 }
 

node/basic/map.go

@@ -428,7 +428,7 @@ type plainMap__ValueAssemblerList struct {
 func (la *plainMap__ValueAssemblerList) AssembleValue() ipld.NodeAssembler {
 	return la.ca.AssembleValue()
 }
-func (plainMap__ValueAssemblerList) ValueStyle() ipld.NodeStyle {
+func (plainMap__ValueAssemblerList) ValueStyle(_ int) ipld.NodeStyle {
 	return Style__Any{}
 }
 

nodeBuilder.go

@@ -101,10 +101,18 @@ type ListAssembler interface {
 	// You often don't need this (because you should be able to
 	// just feed data and check errors), but it's here.
 	//
-	// In contrast to the `MapAssembler.ValueStyle(key)` function,
-	// to determine the ValueStyle for lists we need no parameters;
-	// lists always contain one value type (even if it's "any").
-	ValueStyle() NodeStyle
+	// ValueStyle, much like the matching method on the MapAssembler interface,
+	// requires a parameter specifying the index in the list in order to say
+	// what NodeStyle will be acceptable as a value at that position.
+	// For many lists (and *all* lists which operate exclusively at the Data Model level),
+	// this will return the same NodeStyle regardless of the value of 'idx';
+	// the only time this value will vary is when operating with a Schema,
+	// and handling the representation NodeAssembler for a struct type with
+	// a representation of a list kind.
+	// If you know you are operating in a situation that won't have varying
+	// NodeStyles, it is acceptable to call `ValueStyle(0)` and use the
+	// resulting NodeStyle for all reasoning.
+	ValueStyle(idx int) NodeStyle
 }
 
 type NodeBuilder interface {