Re: [go-nuts] Re: function's argument default value

[Michael Jones]

Reinforcing comments above: defaults are not *missing*, they have been
*avoided*. One can argue default arguments are either a mistake in API
design or neglect in code refactoring.

On the mistake side, the argument is that making "cook(n)" mean "make pizza
if n is missing or cook n if otherwise" adds complexity of comprehension in
exchange for simplicity of expression. Use of varadic arguments does not
change this view that the savings are a deferred cost. As a program user,
extender, debugger, or reviewer, the idea is that you would rather see
cookPizza() and cook(food) in the code, and of course, cookPizza() would
just be cook("pizza"), the inliner would do this in compilation, and the
effect would be as if a default, but the code would be more plain, more
descriptive, and less surprising.

As for refactoring, one need not look far to find an existing C++ API to
which has been added some last-minute parameter, defined as nil or default,
but which allows invisible insertion of new functionality not previously
provided. That is so seductive that most of us have done it. Unfortunately,
it also means that all the old call sites have a hidden secret not visible
to those who read the code. This has proven to be a source of woe. Better
is to refactor the API to best express the new truth and feature set.

These are not "get it to work by yourself" concerns, they are "keep it
working and use it across teams" issues. The notions of Go favor the latter.

On Fri, Aug 24, 2018 at 7:59 AM Louki Sumirniy <
louki.sumirniy.stal...@gmail.com> wrote:

> The distinction you are missing is that Go only considers the *name* of
> an interface method to be unique, meaning only one parameter definition is
> allowed per name. What this means is that in Go these have to be separate
> functions and by definition, differently named. This is why I am suggesting
> that a method of structuring complex objects that is used extensively in
> the standard library is the solution -
>
>
>- you create a function with some set of defaults and no parameter
>- then appropriately named functions
>- and all functions that return no specific other values return the
>pointer to the receiver
>
> Then you can have the same result as only needing to specify parameters
> that differ from defaults, but with the aditional benefit you can create
> multiple configurations for initialisation, loading, copying and
> transferring in from other types especially if they are same as members or
> commutable to members of the receiver type.
>
> On Friday, 24 August 2018 15:15:28 UTC+2, Robert Johnstone wrote:
>>
>> Hello,
>>
>> This is misleading.  With default arguments, there remains only one
>> function definition, which makes it quite different from function
>> overloading where there would be multiple definitions.  Default parameters
>> provides syntax sugar at the call site, but does not create additional
>> functions.
>>
>> I'm not arguing for default parameters.  The explanation in
>> https://talks.golang.org/2012/splash.article#TOC_10 is good, given Go's
>> philosophy.
>>
>> Robert
>>
>>
>> On Thursday, 23 August 2018 19:26:36 UTC-4, Ian Lance Taylor wrote:
>>>
>>> On Thu, Aug 23, 2018 at 4:20 PM, Masoud Ghorbani
>>>  wrote:
>>> > I didn't get the relation of function overloading with parameters
>>> default
>>> > value. actually, function overloading means define functions with
>>> similar
>>> > names.
>>>
>>> Right.  After adding a default value for the parameter, you have two
>>> functions with similar names:
>>> F(int)
>>> F()
>>>
>>> It's exactly as though you overloaded F.
>>>
>>> Ian
>>>
>>>
>>> > On Friday, August 24, 2018 at 1:11:12 AM UTC+4:30, Ian Lance Taylor
>>> wrote:
>>> >>
>>> >> On Thu, Aug 23, 2018 at 12:44 AM, Masoud Ghorbani
>>> >>  wrote:
>>> >> >
>>> >> > Your opinion is like to say all of the python application should
>>> rethink
>>> >> > and
>>> >> > re-write their structure because they used default values. I think
>>> >> > having
>>> >> > default values for parameters is just a feature which will make
>>> codebase
>>> >> > readable and smaller than before.
>>> >>
>>> >> Default values for parameters is in effect a simple form of function
>>> >> overloading.  If F(int) has a default value for the parameter, then
>>> >> you've overloaded F with another function F() that takes no
>>> arguments.
>>> >> Go doesn't have function overloading in general, and it doesn't have
>>> >> default parameter values either.
>>> >>
>>> >> Ian
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups
>>> > "golang-nuts" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> an
>>> > email to golang-nuts...@googlegroups.com.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails 

Re: [go-nuts] Re: function's argument default value

[Louki Sumirniy]

The distinction you are missing is that Go only considers the *name* of an 
interface method to be unique, meaning only one parameter definition is 
allowed per name. What this means is that in Go these have to be separate 
functions and by definition, differently named. This is why I am suggesting 
that a method of structuring complex objects that is used extensively in 
the standard library is the solution -


   - you create a function with some set of defaults and no parameter
   - then appropriately named functions
   - and all functions that return no specific other values return the 
   pointer to the receiver

Then you can have the same result as only needing to specify parameters 
that differ from defaults, but with the aditional benefit you can create 
multiple configurations for initialisation, loading, copying and 
transferring in from other types especially if they are same as members or 
commutable to members of the receiver type.

On Friday, 24 August 2018 15:15:28 UTC+2, Robert Johnstone wrote:
>
> Hello,
>
> This is misleading.  With default arguments, there remains only one 
> function definition, which makes it quite different from function 
> overloading where there would be multiple definitions.  Default parameters 
> provides syntax sugar at the call site, but does not create additional 
> functions.
>
> I'm not arguing for default parameters.  The explanation in 
> https://talks.golang.org/2012/splash.article#TOC_10 is good, given Go's 
> philosophy.  
>
> Robert
>
>
> On Thursday, 23 August 2018 19:26:36 UTC-4, Ian Lance Taylor wrote:
>>
>> On Thu, Aug 23, 2018 at 4:20 PM, Masoud Ghorbani 
>>  wrote: 
>> > I didn't get the relation of function overloading with parameters 
>> default 
>> > value. actually, function overloading means define functions with 
>> similar 
>> > names. 
>>
>> Right.  After adding a default value for the parameter, you have two 
>> functions with similar names: 
>> F(int) 
>> F() 
>>
>> It's exactly as though you overloaded F. 
>>
>> Ian 
>>
>>
>> > On Friday, August 24, 2018 at 1:11:12 AM UTC+4:30, Ian Lance Taylor 
>> wrote: 
>> >> 
>> >> On Thu, Aug 23, 2018 at 12:44 AM, Masoud Ghorbani 
>> >>  wrote: 
>> >> > 
>> >> > Your opinion is like to say all of the python application should 
>> rethink 
>> >> > and 
>> >> > re-write their structure because they used default values. I think 
>> >> > having 
>> >> > default values for parameters is just a feature which will make 
>> codebase 
>> >> > readable and smaller than before. 
>> >> 
>> >> Default values for parameters is in effect a simple form of function 
>> >> overloading.  If F(int) has a default value for the parameter, then 
>> >> you've overloaded F with another function F() that takes no arguments. 
>> >> Go doesn't have function overloading in general, and it doesn't have 
>> >> default parameter values either. 
>> >> 
>> >> Ian 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups 
>> > "golang-nuts" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an 
>> > email to golang-nuts...@googlegroups.com. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: function's argument default value

[Robert Johnstone]

Hello,

This is misleading.  With default arguments, there remains only one 
function definition, which makes it quite different from function 
overloading where there would be multiple definitions.  Default parameters 
provides syntax sugar at the call site, but does not create additional 
functions.

I'm not arguing for default parameters.  The explanation 
in https://talks.golang.org/2012/splash.article#TOC_10 is good, given Go's 
philosophy.  

Robert


On Thursday, 23 August 2018 19:26:36 UTC-4, Ian Lance Taylor wrote:
>
> On Thu, Aug 23, 2018 at 4:20 PM, Masoud Ghorbani 
> > wrote: 
> > I didn't get the relation of function overloading with parameters 
> default 
> > value. actually, function overloading means define functions with 
> similar 
> > names. 
>
> Right.  After adding a default value for the parameter, you have two 
> functions with similar names: 
> F(int) 
> F() 
>
> It's exactly as though you overloaded F. 
>
> Ian 
>
>
> > On Friday, August 24, 2018 at 1:11:12 AM UTC+4:30, Ian Lance Taylor 
> wrote: 
> >> 
> >> On Thu, Aug 23, 2018 at 12:44 AM, Masoud Ghorbani 
> >>  wrote: 
> >> > 
> >> > Your opinion is like to say all of the python application should 
> rethink 
> >> > and 
> >> > re-write their structure because they used default values. I think 
> >> > having 
> >> > default values for parameters is just a feature which will make 
> codebase 
> >> > readable and smaller than before. 
> >> 
> >> Default values for parameters is in effect a simple form of function 
> >> overloading.  If F(int) has a default value for the parameter, then 
> >> you've overloaded F with another function F() that takes no arguments. 
> >> Go doesn't have function overloading in general, and it doesn't have 
> >> default parameter values either. 
> >> 
> >> Ian 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to golang-nuts...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: function's argument default value

[Louki Sumirniy]

I should just add one more thing, something I discovered when I saw the 
cete wrapper for the dgraph's badger KV store: https://github.com/1lann/cete

If you design your interfaces carefully, and make it so that any function 
that does not by necessity return some other type, passes through the 
pointer receiver to the caller. These functions can be strung together in 
long chains, here is an example from a test on one type I have made that 
uses this design pattern:

  
fmt.Println(*NewLockedBuffer().FromRandomBytes(23).FromBytes(NewBytes().FromString(A)).ToBytes().ToString())

By designing it so that type conversions can pass through an intermediate 
type you can push data into and out of your variables, and most 
importantly, if you make a constructor ( NewLockedBuffer() ) and then you 
can write a single function that loads a specific member of the struct, and 
thus for an object with multiple values, it is functionally equivalent to 
the 'default parameter unless specified' model that you get with named 
parameters like in Python and other similar languages. Except it's far 
clearer and reads very well for a human.

One caveat to this design pattern I have noticed, however, because I am 
writing code working with the memguard library, is that you probably should 
be very specific in each of the functions whether it copies, references or 
relocates data from one structure to another. A lack of clarity about this 
could cause all kinds of nasty side effects and complex, hard to solve bugs.

On Friday, 24 August 2018 14:47:21 UTC+2, Louki Sumirniy wrote:
>
> This is in the next section but it's probably even more important:
>
> There is one more aspect of naming to be mentioned: method lookup is 
> always by name only, not by signature (type) of the method. In other words, 
> a single type can never have two methods with the same name. Given a method 
> x.M, there's only ever one M associated with x. Again, this makes it easy 
> to identify which method is referred to given only the name. It also makes 
> the implementation of method invocation simple.
>
> The previous section does explain why this decision was made, it makes it 
> far simpler to write tools to manipulate or analyse the code. One name = 
> only one variable, never any ambiguity to resolve, and this applies also to 
> the human reading it. 
>
> In go you can make functions that accept a slice of interface{}, and in 
> theory you could use this with a switch and either strings or predefined 
> constants (with iota) to create functions that you can interpret any set of 
> parameters with the caveat that a parameter must always be passed to 
> identify each bit of data so you can type assert it.
>
> On Friday, 24 August 2018 14:26:48 UTC+2, Masoud Ghorbani wrote:
>>
>> I found this talks which 
>> Rob Pike at syntax 
>> section 
>> explained why they omitted default function arguments.
>> Thanks all about this discussion.
>>
>> On Friday, August 24, 2018 at 5:21:37 AM UTC+4:30, andrey mirtchovski 
>> wrote:
>>>
>>> > You're right but I think developers of Go can think about that because 
>>> its benefits are obvious. 
>>>
>>> can you please enumerate those benefits? many gophers are not 
>>> convinced they are obvious. 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: function's argument default value

[Louki Sumirniy]

This is in the next section but it's probably even more important:

There is one more aspect of naming to be mentioned: method lookup is always 
by name only, not by signature (type) of the method. In other words, a 
single type can never have two methods with the same name. Given a method 
x.M, there's only ever one M associated with x. Again, this makes it easy 
to identify which method is referred to given only the name. It also makes 
the implementation of method invocation simple.

The previous section does explain why this decision was made, it makes it 
far simpler to write tools to manipulate or analyse the code. One name = 
only one variable, never any ambiguity to resolve, and this applies also to 
the human reading it. 

In go you can make functions that accept a slice of interface{}, and in 
theory you could use this with a switch and either strings or predefined 
constants (with iota) to create functions that you can interpret any set of 
parameters with the caveat that a parameter must always be passed to 
identify each bit of data so you can type assert it.

On Friday, 24 August 2018 14:26:48 UTC+2, Masoud Ghorbani wrote:
>
> I found this talks which 
> Rob Pike at syntax 
> section 
> explained why they omitted default function arguments.
> Thanks all about this discussion.
>
> On Friday, August 24, 2018 at 5:21:37 AM UTC+4:30, andrey mirtchovski 
> wrote:
>>
>> > You're right but I think developers of Go can think about that because 
>> its benefits are obvious. 
>>
>> can you please enumerate those benefits? many gophers are not 
>> convinced they are obvious. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: function's argument default value

[Masoud Ghorbani]

I found this talks which Rob 
Pike at syntax section 
explained why they omitted default function arguments.
Thanks all about this discussion.

On Friday, August 24, 2018 at 5:21:37 AM UTC+4:30, andrey mirtchovski wrote:
>
> > You're right but I think developers of Go can think about that because 
> its benefits are obvious. 
>
> can you please enumerate those benefits? many gophers are not 
> convinced they are obvious. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: function's argument default value

[Louki Sumirniy]

I don't think the benefits are obvious and being able to leave out 
parameters by specifying one by name is of dubious benefit. Could you not 
simply write a short set of if statements that insert a default by using a 
nulled sentinel. Like this:

func PrintMessage(s string) {
  if s == "" {
s = "default value"
  }
  DoSomeThing(s)
}

Then call it

PrintMessage("")



On Friday, 24 August 2018 01:38:36 UTC+2, Masoud Ghorbani wrote:
>
> You're right but I think developers of Go can think about that because its 
> benefits are obvious.
>
> On Friday, August 24, 2018 at 1:23:32 AM UTC+4:30, Axel Wagner wrote:
>>
>> On Thu, Aug 23, 2018 at 9:44 AM Masoud Ghorbani  
>> wrote:
>>
>>> Your opinion is like to say all of the python application should rethink 
>>> and re-write their structure because they used default values.
>>>
>>
>> One general thing to observe in all these discussions is, that Go is not 
>> Python (or Rust, Haskell, C#,…). Different languages have different goals, 
>> weigh them differently and choose different solutions to get there - and 
>> that's okay. Saying something isn't right for Go isn't the same as saying 
>> something isn't right for a different language. In the same way, saying 
>> some other language is doing something is not a convincing argument that Go 
>> should do it too.
>>  
>>
>>> I think having default values for parameters is just a feature which 
>>> will make codebase readable and smaller than before.
>>>
>>> On Thursday, August 23, 2018 at 4:38:23 AM UTC+4:30, Louki Sumirniy 
>>> wrote:

 There is a default value for everything in Go. Null. 0, "" and nil. As 
 someone else said, if you want a parameter to be optional you probably 
 need 
 ...interface{} and then infer no parameter as 'use the default'. Going a 
 little further, you can build default values into a constructor function 
 for an interfaced type. 

 Oh, probably the neatest solution is to make a struct that lets you 
 input the parameters either in-order or with labels instead. Then you can 
 use &TypeName{} to mean 'use defaults' or whichever parameters are not 
 specified get automatically set to default, either unlabeled and ordered 
 such that the values that will be asserted to defaults are not the first 
 ones in a struct literal used to feed parameters in. Or make the names 
 nice 
 and concise so they aren't troublesome to add (and if your code is going 
 to 
 often use defaults, probably you won't even have to specify many values 
 very often anyway).

 Assertions and labeled parameters are nice features but they don't 
 really save you that much time. I would suggest that it's more likely you 
 need to rethink the structure of your application and make slightly 
 different named parameters for those calls that will use defaults for 
 specific parameters.

 Another thing is that you can make null variables imply the use of 
 defaults, then you only need to put 'nil' '""' or '0' into these 
 parameters 
 and the code will test and fill them automatically. Or if null isn't 
 handy, 
 you can define sentinel values for a type that indicate 'use defaults'.

 On Wednesday, 22 August 2018 14:39:37 UTC+2, Masoud Ghorbani wrote:
>
> Why there isn't function argument default value in Golang explicitly 
> like Typescript and Python?
>
 -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: function's argument default value

[Louki Sumirniy]

I have to agree. The idiomatic solution would be defining multiple 
functions that wrap around another, and it is not onerously boilerplatey. 
As Ian says, default values do constitute effectively function overloads.

There is  reason why function overloading is not available in Go. Just go 
look at some typical c++ code. Not only overloading but operator 
overloading as well. Looking at one source file you may not be able to 
figure out what any symbol in the file actually refers to. Watch the way 
symbol analysis tools like Codelens give you references to a given 
symbol... I know in the bitcoin codebase, nearly every symbol in the whole 
damn codebase codelens suggests like 5 different definitions for 
everything. One of them is correct, of course, but the only way to find out 
is to compile it, and an eternity later it just does stuff and because the 
source code is so difficult to analyse, you are still none the wiser.

I would think that for those who really really need such  feature, the 
solution would be with using a code generator/preprocessor. But then you 
will lose a lot of the advantage of writing it in Go in the first place.

On Friday, 24 August 2018 02:51:37 UTC+2, andrey mirtchovski wrote:
>
> > You're right but I think developers of Go can think about that because 
> its benefits are obvious. 
>
> can you please enumerate those benefits? many gophers are not 
> convinced they are obvious. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: function's argument default value

[andrey mirtchovski]

> You're right but I think developers of Go can think about that because its 
> benefits are obvious.

can you please enumerate those benefits? many gophers are not
convinced they are obvious.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: function's argument default value

[Masoud Ghorbani]

You're right but I think developers of Go can think about that because its 
benefits are obvious.

On Friday, August 24, 2018 at 1:23:32 AM UTC+4:30, Axel Wagner wrote:
>
> On Thu, Aug 23, 2018 at 9:44 AM Masoud Ghorbani  > wrote:
>
>> Your opinion is like to say all of the python application should rethink 
>> and re-write their structure because they used default values.
>>
>
> One general thing to observe in all these discussions is, that Go is not 
> Python (or Rust, Haskell, C#,…). Different languages have different goals, 
> weigh them differently and choose different solutions to get there - and 
> that's okay. Saying something isn't right for Go isn't the same as saying 
> something isn't right for a different language. In the same way, saying 
> some other language is doing something is not a convincing argument that Go 
> should do it too.
>  
>
>> I think having default values for parameters is just a feature which will 
>> make codebase readable and smaller than before.
>>
>> On Thursday, August 23, 2018 at 4:38:23 AM UTC+4:30, Louki Sumirniy wrote:
>>>
>>> There is a default value for everything in Go. Null. 0, "" and nil. As 
>>> someone else said, if you want a parameter to be optional you probably need 
>>> ...interface{} and then infer no parameter as 'use the default'. Going a 
>>> little further, you can build default values into a constructor function 
>>> for an interfaced type. 
>>>
>>> Oh, probably the neatest solution is to make a struct that lets you 
>>> input the parameters either in-order or with labels instead. Then you can 
>>> use &TypeName{} to mean 'use defaults' or whichever parameters are not 
>>> specified get automatically set to default, either unlabeled and ordered 
>>> such that the values that will be asserted to defaults are not the first 
>>> ones in a struct literal used to feed parameters in. Or make the names nice 
>>> and concise so they aren't troublesome to add (and if your code is going to 
>>> often use defaults, probably you won't even have to specify many values 
>>> very often anyway).
>>>
>>> Assertions and labeled parameters are nice features but they don't 
>>> really save you that much time. I would suggest that it's more likely you 
>>> need to rethink the structure of your application and make slightly 
>>> different named parameters for those calls that will use defaults for 
>>> specific parameters.
>>>
>>> Another thing is that you can make null variables imply the use of 
>>> defaults, then you only need to put 'nil' '""' or '0' into these parameters 
>>> and the code will test and fill them automatically. Or if null isn't handy, 
>>> you can define sentinel values for a type that indicate 'use defaults'.
>>>
>>> On Wednesday, 22 August 2018 14:39:37 UTC+2, Masoud Ghorbani wrote:

 Why there isn't function argument default value in Golang explicitly 
 like Typescript and Python?

>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: function's argument default value

[Ian Lance Taylor]

On Thu, Aug 23, 2018 at 4:20 PM, Masoud Ghorbani
 wrote:
> I didn't get the relation of function overloading with parameters default
> value. actually, function overloading means define functions with similar
> names.

Right.  After adding a default value for the parameter, you have two
functions with similar names:
F(int)
F()

It's exactly as though you overloaded F.

Ian


> On Friday, August 24, 2018 at 1:11:12 AM UTC+4:30, Ian Lance Taylor wrote:
>>
>> On Thu, Aug 23, 2018 at 12:44 AM, Masoud Ghorbani
>>  wrote:
>> >
>> > Your opinion is like to say all of the python application should rethink
>> > and
>> > re-write their structure because they used default values. I think
>> > having
>> > default values for parameters is just a feature which will make codebase
>> > readable and smaller than before.
>>
>> Default values for parameters is in effect a simple form of function
>> overloading.  If F(int) has a default value for the parameter, then
>> you've overloaded F with another function F() that takes no arguments.
>> Go doesn't have function overloading in general, and it doesn't have
>> default parameter values either.
>>
>> Ian
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: function's argument default value

[Masoud Ghorbani]

I didn't get the relation of function overloading with parameters default 
value. actually, *function overloading* 
 
means define functions with similar names.

On Friday, August 24, 2018 at 1:11:12 AM UTC+4:30, Ian Lance Taylor wrote:
>
> On Thu, Aug 23, 2018 at 12:44 AM, Masoud Ghorbani 
> > wrote: 
> > 
> > Your opinion is like to say all of the python application should rethink 
> and 
> > re-write their structure because they used default values. I think 
> having 
> > default values for parameters is just a feature which will make codebase 
> > readable and smaller than before. 
>
> Default values for parameters is in effect a simple form of function 
> overloading.  If F(int) has a default value for the parameter, then 
> you've overloaded F with another function F() that takes no arguments. 
> Go doesn't have function overloading in general, and it doesn't have 
> default parameter values either. 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: function's argument default value

['Axel Wagner' via golang-nuts]

On Thu, Aug 23, 2018 at 9:44 AM Masoud Ghorbani 
wrote:

> Your opinion is like to say all of the python application should rethink
> and re-write their structure because they used default values.
>

One general thing to observe in all these discussions is, that Go is not
Python (or Rust, Haskell, C#,…). Different languages have different goals,
weigh them differently and choose different solutions to get there - and
that's okay. Saying something isn't right for Go isn't the same as saying
something isn't right for a different language. In the same way, saying
some other language is doing something is not a convincing argument that Go
should do it too.


> I think having default values for parameters is just a feature which will
> make codebase readable and smaller than before.
>
> On Thursday, August 23, 2018 at 4:38:23 AM UTC+4:30, Louki Sumirniy wrote:
>>
>> There is a default value for everything in Go. Null. 0, "" and nil. As
>> someone else said, if you want a parameter to be optional you probably need
>> ...interface{} and then infer no parameter as 'use the default'. Going a
>> little further, you can build default values into a constructor function
>> for an interfaced type.
>>
>> Oh, probably the neatest solution is to make a struct that lets you input
>> the parameters either in-order or with labels instead. Then you can use
>> &TypeName{} to mean 'use defaults' or whichever parameters are not
>> specified get automatically set to default, either unlabeled and ordered
>> such that the values that will be asserted to defaults are not the first
>> ones in a struct literal used to feed parameters in. Or make the names nice
>> and concise so they aren't troublesome to add (and if your code is going to
>> often use defaults, probably you won't even have to specify many values
>> very often anyway).
>>
>> Assertions and labeled parameters are nice features but they don't really
>> save you that much time. I would suggest that it's more likely you need to
>> rethink the structure of your application and make slightly different named
>> parameters for those calls that will use defaults for specific parameters.
>>
>> Another thing is that you can make null variables imply the use of
>> defaults, then you only need to put 'nil' '""' or '0' into these parameters
>> and the code will test and fill them automatically. Or if null isn't handy,
>> you can define sentinel values for a type that indicate 'use defaults'.
>>
>> On Wednesday, 22 August 2018 14:39:37 UTC+2, Masoud Ghorbani wrote:
>>>
>>> Why there isn't function argument default value in Golang explicitly
>>> like Typescript and Python?
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: function's argument default value

[Ian Lance Taylor]

On Thu, Aug 23, 2018 at 12:44 AM, Masoud Ghorbani
 wrote:
>
> Your opinion is like to say all of the python application should rethink and
> re-write their structure because they used default values. I think having
> default values for parameters is just a feature which will make codebase
> readable and smaller than before.

Default values for parameters is in effect a simple form of function
overloading.  If F(int) has a default value for the parameter, then
you've overloaded F with another function F() that takes no arguments.
Go doesn't have function overloading in general, and it doesn't have
default parameter values either.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: function's argument default value

[Louki Sumirniy]

Actually, going a little further, I would like to see a change in Golang 
where parameter and return tuples can be set the same way as structs - so 
if you use named labels ( label="value ) it assumes null for any others 
specified. Then you can add one more feature, which is also related and 
gives you what you want - that you can specify defaults inside the 
parameter block in a function header for values when you want something 
other than null values when unspecified using labels.

On Thursday, 23 August 2018 09:44:17 UTC+2, Masoud Ghorbani wrote:
>
> Your opinion is like to say all of the python application should rethink 
> and re-write their structure because they used default values. I think 
> having default values for parameters is just a feature which will make 
> codebase readable and smaller than before.
>
> On Thursday, August 23, 2018 at 4:38:23 AM UTC+4:30, Louki Sumirniy wrote:
>>
>> There is a default value for everything in Go. Null. 0, "" and nil. As 
>> someone else said, if you want a parameter to be optional you probably need 
>> ...interface{} and then infer no parameter as 'use the default'. Going a 
>> little further, you can build default values into a constructor function 
>> for an interfaced type. 
>>
>> Oh, probably the neatest solution is to make a struct that lets you input 
>> the parameters either in-order or with labels instead. Then you can use 
>> &TypeName{} to mean 'use defaults' or whichever parameters are not 
>> specified get automatically set to default, either unlabeled and ordered 
>> such that the values that will be asserted to defaults are not the first 
>> ones in a struct literal used to feed parameters in. Or make the names nice 
>> and concise so they aren't troublesome to add (and if your code is going to 
>> often use defaults, probably you won't even have to specify many values 
>> very often anyway).
>>
>> Assertions and labeled parameters are nice features but they don't really 
>> save you that much time. I would suggest that it's more likely you need to 
>> rethink the structure of your application and make slightly different named 
>> parameters for those calls that will use defaults for specific parameters.
>>
>> Another thing is that you can make null variables imply the use of 
>> defaults, then you only need to put 'nil' '""' or '0' into these parameters 
>> and the code will test and fill them automatically. Or if null isn't handy, 
>> you can define sentinel values for a type that indicate 'use defaults'.
>>
>> On Wednesday, 22 August 2018 14:39:37 UTC+2, Masoud Ghorbani wrote:
>>>
>>> Why there isn't function argument default value in Golang explicitly 
>>> like Typescript and Python?
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: function's argument default value

[Louki Sumirniy]

Actually, my real opinion is that I like these default argument values, I 
also like concise asserts at the head of functions that automatically 
sanitise data. But they cost quite a lot which is likely why Go doesn't 
have them. Default arguments are the least useful of the two, asserts have 
a much greater effect on correctness which is why many functional languages 
let you set such conditions in a function.

On Thursday, 23 August 2018 09:44:17 UTC+2, Masoud Ghorbani wrote:
>
> Your opinion is like to say all of the python application should rethink 
> and re-write their structure because they used default values. I think 
> having default values for parameters is just a feature which will make 
> codebase readable and smaller than before.
>
> On Thursday, August 23, 2018 at 4:38:23 AM UTC+4:30, Louki Sumirniy wrote:
>>
>> There is a default value for everything in Go. Null. 0, "" and nil. As 
>> someone else said, if you want a parameter to be optional you probably need 
>> ...interface{} and then infer no parameter as 'use the default'. Going a 
>> little further, you can build default values into a constructor function 
>> for an interfaced type. 
>>
>> Oh, probably the neatest solution is to make a struct that lets you input 
>> the parameters either in-order or with labels instead. Then you can use 
>> &TypeName{} to mean 'use defaults' or whichever parameters are not 
>> specified get automatically set to default, either unlabeled and ordered 
>> such that the values that will be asserted to defaults are not the first 
>> ones in a struct literal used to feed parameters in. Or make the names nice 
>> and concise so they aren't troublesome to add (and if your code is going to 
>> often use defaults, probably you won't even have to specify many values 
>> very often anyway).
>>
>> Assertions and labeled parameters are nice features but they don't really 
>> save you that much time. I would suggest that it's more likely you need to 
>> rethink the structure of your application and make slightly different named 
>> parameters for those calls that will use defaults for specific parameters.
>>
>> Another thing is that you can make null variables imply the use of 
>> defaults, then you only need to put 'nil' '""' or '0' into these parameters 
>> and the code will test and fill them automatically. Or if null isn't handy, 
>> you can define sentinel values for a type that indicate 'use defaults'.
>>
>> On Wednesday, 22 August 2018 14:39:37 UTC+2, Masoud Ghorbani wrote:
>>>
>>> Why there isn't function argument default value in Golang explicitly 
>>> like Typescript and Python?
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: function's argument default value

[Masoud Ghorbani]

Your opinion is like to say all of the python application should rethink 
and re-write their structure because they used default values. I think 
having default values for parameters is just a feature which will make 
codebase readable and smaller than before.

On Thursday, August 23, 2018 at 4:38:23 AM UTC+4:30, Louki Sumirniy wrote:
>
> There is a default value for everything in Go. Null. 0, "" and nil. As 
> someone else said, if you want a parameter to be optional you probably need 
> ...interface{} and then infer no parameter as 'use the default'. Going a 
> little further, you can build default values into a constructor function 
> for an interfaced type. 
>
> Oh, probably the neatest solution is to make a struct that lets you input 
> the parameters either in-order or with labels instead. Then you can use 
> &TypeName{} to mean 'use defaults' or whichever parameters are not 
> specified get automatically set to default, either unlabeled and ordered 
> such that the values that will be asserted to defaults are not the first 
> ones in a struct literal used to feed parameters in. Or make the names nice 
> and concise so they aren't troublesome to add (and if your code is going to 
> often use defaults, probably you won't even have to specify many values 
> very often anyway).
>
> Assertions and labeled parameters are nice features but they don't really 
> save you that much time. I would suggest that it's more likely you need to 
> rethink the structure of your application and make slightly different named 
> parameters for those calls that will use defaults for specific parameters.
>
> Another thing is that you can make null variables imply the use of 
> defaults, then you only need to put 'nil' '""' or '0' into these parameters 
> and the code will test and fill them automatically. Or if null isn't handy, 
> you can define sentinel values for a type that indicate 'use defaults'.
>
> On Wednesday, 22 August 2018 14:39:37 UTC+2, Masoud Ghorbani wrote:
>>
>> Why there isn't function argument default value in Golang explicitly like 
>> Typescript and Python?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: function's argument default value

[Louki Sumirniy]

There is a default value for everything in Go. Null. 0, "" and nil. As 
someone else said, if you want a parameter to be optional you probably need 
...interface{} and then infer no parameter as 'use the default'. Going a 
little further, you can build default values into a constructor function 
for an interfaced type. 

Oh, probably the neatest solution is to make a struct that lets you input 
the parameters either in-order or with labels instead. Then you can use 
&TypeName{} to mean 'use defaults' or whichever parameters are not 
specified get automatically set to default, either unlabeled and ordered 
such that the values that will be asserted to defaults are not the first 
ones in a struct literal used to feed parameters in. Or make the names nice 
and concise so they aren't troublesome to add (and if your code is going to 
often use defaults, probably you won't even have to specify many values 
very often anyway).

Assertions and labeled parameters are nice features but they don't really 
save you that much time. I would suggest that it's more likely you need to 
rethink the structure of your application and make slightly different named 
parameters for those calls that will use defaults for specific parameters.

Another thing is that you can make null variables imply the use of 
defaults, then you only need to put 'nil' '""' or '0' into these parameters 
and the code will test and fill them automatically. Or if null isn't handy, 
you can define sentinel values for a type that indicate 'use defaults'.

On Wednesday, 22 August 2018 14:39:37 UTC+2, Masoud Ghorbani wrote:
>
> Why there isn't function argument default value in Golang explicitly like 
> Typescript and Python?
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.