thoughts on 'inout'


(Oliver M) #1

Regarding In-Out Parameters:
My gut reaction to typing 'inout' in front of every parameter I want to call by reference is that it makes code look rather waffly.
So I'm reflecting an idea on this:

Use = to assign values.
Use : to associate variables.

A function declaration would look like this:
func addInt(add intToAdd = Int, to counterInt : Int ) {
counterInt += intToAdd
}

Here is example code for a game of 'think of a number' where you pick a random number and do some basic maths on it.

//declare the function
func multiplyAdd(multiplyBy intToMultiply = Int, add intToAdd = Int, toNumber pickedInt : Int) { pickedInt *= intToMultiply pickedInt += intToAdd
}

//declare some variables
var multiplier = 2var adder = 3var pickNumber = 4

//call the function
multiplyAdd(multiplyBy = multiplier, add = adder, toNumber : pickNumber)

It takes a little getting used to, but it does look quite clean.


(Brent Royal-Gordon) #2

My gut reaction to typing 'inout' in front of every parameter I want to call by reference is that it makes code look rather waffly.

So I'm reflecting an idea on this:

Use = to assign values.

Use : to associate variables.

A function declaration would look like this:

func addInt(add intToAdd = Int, to counterInt : Int ) {
    counterInt += intToAdd
}

This doesn't work with unlabeled parameters. I think it also makes inout parameters too invisible; they have unusual semantics and ought to be marked. I don't think it's a good idea to overload `=` for parameter passing; it requires different spacing to look right, and the change would alter literally every method call in existing code. `=` is also semantically heavier than `:`, and yet it's being used in the lighter role here. And I think it makes inout parameters too "easy"—they're a pretty rare case and it's okay to require more than zero extra characters to declare them.

In short, -1.

···

--
Brent Royal-Gordon
Architechies


(Haravikk) #3

It’s a nice idea, but I have to agree with Brent; I think that while it’s concise, it’s not necessarily clear, especially if a function may have both inout parameters and parameters with default values. Also I tend to favour a little bit of extra verbosity, especially on things that may not be used a lot (depends on what you’re doing of course); while inout isn’t my favourite term it’s at least fairly clear of what it’s for to someone encountering it for the first time, though I might have gone with reference, or ref (in keeping with the three letter var and let) but that may just be me.

···

On 11 Feb 2016, at 23:29, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

My gut reaction to typing 'inout' in front of every parameter I want to call by reference is that it makes code look rather waffly.

So I'm reflecting an idea on this:

Use = to assign values.

Use : to associate variables.

A function declaration would look like this:

func addInt(add intToAdd = Int, to counterInt : Int ) {
   counterInt += intToAdd
}

This doesn't work with unlabeled parameters. I think it also makes inout parameters too invisible; they have unusual semantics and ought to be marked. I don't think it's a good idea to overload `=` for parameter passing; it requires different spacing to look right, and the change would alter literally every method call in existing code. `=` is also semantically heavier than `:`, and yet it's being used in the lighter role here. And I think it makes inout parameters too "easy"—they're a pretty rare case and it's okay to require more than zero extra characters to declare them.

In short, -1.


(Radek Pietruszewski) #4

If we were to change stuff for greater conciseness, don’t you think

  func addInt(a: &Int, b: &Int)
  addInt(&a, &b)

would be a less confusing solution than messing with : and = ?

— Radek

···

On 12 Feb 2016, at 00:17, Oliver M via swift-evolution <swift-evolution@swift.org> wrote:

Regarding In-Out Parameters:

My gut reaction to typing 'inout' in front of every parameter I want to call by reference is that it makes code look rather waffly.

So I'm reflecting an idea on this:

Use = to assign values.

Use : to associate variables.

A function declaration would look like this:

func addInt(add intToAdd = Int, to counterInt : Int ) {
    counterInt += intToAdd
}

Here is example code for a game of 'think of a number' where you pick a random number and do some basic maths on it.

//declare the function

func multiplyAdd(multiplyBy intToMultiply = Int, add intToAdd = Int, toNumber pickedInt : Int) {
    pickedInt *= intToMultiply
    pickedInt += intToAdd
}

//declare some variables

var multiplier = 2
var adder = 3
var pickNumber = 4

//call the function

multiplyAdd(multiplyBy = multiplier, add = adder, toNumber : pickNumber)

It takes a little getting used to, but it does look quite clean.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Alexey Demedetskiy) #5

I would like to read it exactly opposite :slight_smile:

func addInt(inout a: Int, inout b: Int)
addInt(inout a, inout b)

But +1 for unified semantic anyway.

···

func addInt(a:&Int, b:&Int)
addInt(&a,&b)

Cc:"swift-evolution@swift.org"<swift-evolution@swift.org>
Subject:[swift-evolution] thoughts on 'inout'
Date:12 февраля 2016 г., 01:51:10 GMT+2

If we were to change stuff for greater conciseness, don’t you think

func addInt(a:&Int, b:&Int)
addInt(&a,&b)

would be a less confusing solution than messing with : and = ?
— Radek
> On 12 Feb 2016, at 00:17, Oliver M via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
> Regarding In-Out Parameters:
>
> My gut reaction to typing 'inout' in front of every parameter I want to call by reference is that it makes code look rather waffly.
>
> So I'm reflecting an idea on this:
>
>
> Use = to assign values.
>
> Use : to associate variables.
>
>
>
> A function declaration would look like this:
>
> func addInt(add intToAdd = Int, to counterInt : Int ) {
> counterInt += intToAdd
> }
>
>
>
> Here is example code for a game of 'think of a number' where you pick a random number and do some basic maths on it.
>
> //declare the function
>
> func multiplyAdd(multiplyBy intToMultiply = Int, add intToAdd = Int, toNumber pickedInt : Int) {
> pickedInt*= intToMultiply
> pickedInt+= intToAdd
> }
>
>
> //declare some variables
>
> var multiplier = 2
> var adder = 3
> var pickNumber = 4
>
>
> //call the function
>
> multiplyAdd(multiplyBy = multiplier, add = adder, toNumber : pickNumber)
>
>
> It takes a little getting used to, but it does look quite clean.
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> https://lists.swift.org/mailman/listinfo/swift-evolution


(Oliver M) #6

@Brent Royal-GordonThe code below is with different spacing for = and : so it should look more distinguishable and familiar.I'm not sure what you mean by heavier and lighter.I've never looked at the statement var a = 7and wished I could use a lighter : instead of the =(did I understand you correctly on this point?)inout parameters are not rare in my code. I'd say they are about as common as only in parameters,and even then, the vast majority of my functions have them.

//main body code:
expandFibonacciSequence(inArray: fibonacciArray, by = 100)
combine(transform = localTransform, withTransform = parentTransform, toOutput: globalTransform)
addNoise(toColours: colourArray, withMaxRandomFactor = 0.05, outputColours: noisyColourArray)

//the corresponding function declarations:
expandFibonacciSequence(inArray numberArray: [Ints], by maxAdditions = Int) { var inCount = numberArray.count for addIndex in 0…(maxAdditions - 1) { numberArray[inCount + addIndex] = numberArray[inCount + addIndex - 1] + numberArray[inCount + addIndex - 2] }}

addNoise(toColours originalColours: [Double], withMaxRandomFactor maxFactor = 0.05, outputColours newColours: [Double]) { //the originalColours array is passed by reference (associated variable) to keep memory usage low.
let numOfColours = originalColours.count for index in 0…numOfColours { let randomNumber = drand48() * maxFactor - maxFactor/2 newColours[index] = originalColours[index] + randomNumber }}

combine(transform localMatrix = [double], withTransform parentMatrix = [double], toOutput outputMatrix: [double]) { outputMatrix[0] = localMatrix[0] * parentMatrix[0] + localMatrix[1] * parentMatrix[4] + localMatrix[2] * parentMatrix[8] + localMatrix[3] * parentMatrix[12] outputMatrix[1] = localMatrix[0] * parentMatrix[1] + localMatrix[1] * parentMatrix[5] + localMatrix[2] * parentMatrix[9] + localMatrix[3] * parentMatrix[13] //outputMatrix[2] ... //outputMatrix[3] … //outputMatrix[4] ... //and so on }


(Brent Royal-Gordon) #7

I'm not sure what you mean by heavier and lighter.
I've never looked at the statement
var a = 7
and wished I could use a lighter : instead of the =
(did I understand you correctly on this point?)

What I mean is that `:` is visually "smaller" than `=`; when you're reading code, it shows up less prominently. That means colon is better suited for the more common and less dangerous role of marking in-only parameters.

inout parameters are not rare in my code. I'd say they are about as common as only in parameters,
and even then, the vast majority of my functions have them.

Then I think you're writing in a fairly unusual style, which may explain the disconnect. Most Swift code I've seen uses inout parameters very rarely—perhaps one function in fifty will have an inout parameter.

Are you sure that using inout instead of passing, modifying, and returning the arrays is gaining you anything? Swift arrays are backed by copy-on-write storage, so in theory with optimizations enabled you might not not need to copy the data in a pass-and-assign-back pattern. If this were the case, it would probably only show up in optimized builds, not debug builds.

···

--
Brent Royal-Gordon
Architechies