[go-nuts] Allow name : type declarations?

[Hugh Fisher]

I'm a new Go programmer (learning in my spare time) and decided to share my
initial fumbles and what? why? moments while they're still fresh.

First suggestion: allow a colon to be inserted between the name(s) and type
in declarations. For example

x : int

func random(): real 


Back in the previous century I wrote a lot of Pascal code and a little Ada, 
so
I'm fine with the idea of Go reversing the declaration syntax away from C. 
But
because of that experience I keep typing a colon between the names.

For those without Pascal experience, I still think it would be worthwhile 
for
consistency and readability.

Consistency: we already have name = value and name := value and type.
The : becomes the 'type declaration' operator.

For readability, while I appreciate the intent to shorten the code, I find 
it takes
longer for me to parse

x, y, z int


because the absence of the comma is what matters. It's significant white 
space,
(which again I'm generally OK with) but very short. I find it harder to 
look for
something that isn't there, rather than a divider or delimiter. Already I 
seem to
be inserting extra spaces before the type name just to make it stand out.

cheers,
Hugh Fisher

-- 
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: Accessing Slices Made From Same Array Concurrently

[silviucapota]

Hi Kaveh,

Change the line:
*ptr = append(*ptr, []byte(fmt.Sprint*f("%02d"*, k1))...)

to
*ptr = append(*ptr, []byte(fmt.Sprintf(*"%15d"*, k1))...)

The buckets will overlap (more than 10 bytes) and you will get the race 
triggered in the detector

Silviu


On Saturday, 21 April 2018 12:40:04 UTC-4, Kaveh Shahbazian wrote:
>
> @Ankit That's what I thought. Yet the code is accessing the same 
> underlying array. That is the part that worries me and -race does not 
> complain.
>
> @Louki Still no complain from -race! https://play.golang.org/p/dUt0QE63RDK
>
> On Saturday, April 21, 2018 at 7:01:25 PM UTC+4:30, Louki Sumirniy wrote:
>>
>> Unless you pass pointers in Go, every time you hop in and out of a new 
>> scope any changes are discarded. This is why unless you type-bind with 
>> pointers you don't actually have an OOP method, as the function will not 
>> act upon the parent variable/structure.
>>
>> I think if you change your playground code to pass pointers into the 
>> goroutines you'll either see race detector or clobbering.
>>
>> On Saturday, 21 April 2018 16:30:22 UTC+3, Ankit Gupta wrote:
>>>
>>> @Kaveh
>>>
>>> Slices are values but they refer to the same back array location. You 
>>> have created localized v which is appended inside goroutine which refer to 
>>> a location containing its own byte array of len=10. So, you are not really 
>>> referencing the same memory location as other v slice in the goroutine. You 
>>> will be affected if you remove k,v:=k,v or append more than 10 bytes to v 
>>> inside goroutine which will take up space on next slice's bytes. 
>>>
>>> On Saturday, April 21, 2018 at 2:30:53 PM UTC+5:30, Kaveh Shahbazian 
>>> wrote:

 @ Louki Sumirniy
 Slices are values AFAIK. There is no passby pointer.

 And the point is, race detector does not flag anything: 
 https://play.golang.org/p/NC8mBwS1-0P

>>>

-- 
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: proposal: disallow implicitly comparing true with value of interface{} in a switch with no value

[Louki Sumirniy]

Your syntax is wrong. I think you mean this:

var someInterfaceValue interface{}

// do something that puts a value in above variable

switch someInterfaceValue {
  case true:
// do something
  default:
// do something else
}

On Saturday, 21 April 2018 16:30:22 UTC+3, b97...@gmail.com wrote:
>
> var someInterfaceValue interface{}
> switch {
> case someInterfaceValue:  // proposal: compile error: non-bool used as 
> condition
> case someInterfaceValue == true: // OK
> }
>
> Sometimes carefulness is just not enough.
> One may type a wrong variable as the case condition, or a incomplete 
> condition.
> Why is this special? Because it's commonly used.
>

-- 
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: On Accepting Interfaces and Structs

[Louki Sumirniy]

I only just finally wrapped my head around this stuff and forgive me if I 
have missed the point of the question but this is what my code has:

type AbstractType alias/struct {}

type abstractthing interface {
  DoSomething(interface{})
}

func (a *AbstractType) DoSomething(b AbstractType) {

}

and then in my implementer:

import ( 
  "previousclass/path"
)

type ConcreteType alias/struct {}

func (c *ConcreteType) DoSomething(t ConcreteType) {

}

You have to create a dummy function in the abstract type's source file in 
order to use it in the superclass, as it effectively is, in order to use 
its generalised functionality, but your app imports the second one, which 
sucks up everything from the first and the function bound to the concrete 
type overrides the abstract functions in the superclass, allowing you to 
generalise part of the superclass and enable you to write a set of 
functions with part of the implementation (for example, a tree store) while 
letting you change the data type to something else. It's composition, as 
opposed to inheritance.

On Saturday, 21 April 2018 14:51:55 UTC+3, Kaveh Shahbazian wrote:
>
> Regarding "Accept interfaces, return concrete types", how can it be 
> applied for structs that represent a payload/value?
>
> For example in package first, logger is defined as:
>
> type logger interface {
> Debugf(template string, args ...interface{})
> Errorf(template string, args ...interface{})
> Infof(template string, args ...interface{})
> }
>
> And package first only accepts a logger that implements the logger 
> interface.
>
> Now lets assume there is a need for passing a struct too, like some config 
> or state.
>
> This causes importing the original package that, that config or state 
> struct resides in; while package first is happily accepting other things 
> from that package using interfaces.
>
> For example in package second there is some tool that is represented using 
> this interface in package first:
>
> type cloner interface {
> Clone() (*second.State, error)
> }
>
>
> As it can be seen, now package first has to explicitly import package 
> second, because of the type *second.State.
>
> Currently I break things by renaming the second package to something 
> meaningless when importing like:
>
> type cloner interface {
> Clone() (*p2nd.State, error)
> }
>
> But this is not really a work around and package second leaks into the 
> scope of package first anyway.
>
> Is there a way to actually achieve this?
>

-- 
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: http "alt" attribute value for img tag?

[Nigel Tao]

package main

import (
"fmt"
"log"
"strings"

"golang.org/x/net/html"
)

func main() {
const src = `

message




`

doc, err := html.Parse(strings.NewReader(src))
if err != nil {
log.Fatal(err)
}
var f func(*html.Node)
f = func(n *html.Node) {
if n.Type == html.ElementNode && n.Data == "img" {
for _, a := range n.Attr {
if a.Key == "alt" {
fmt.Printf("a.Key=%q a.Val=%q\n", a.Key, a.Val)
break
}
}
}
for c := n.FirstChild; c != nil; c = c.NextSibling {
f(c)
}
}
f(doc)
}

-- 
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] On Accepting Interfaces and Structs

[Kaveh Shahbazian]

You might be right. Probably I am fixating on something that I do not 
understand well and just have a not positive feeling about it. But two 
things:

1 - Other packages (will) have implementations that satisfies first.cloner 
so there might be:

type cloner interface {
Clone() (*third.State, error)
}

Should I put the State struct in it's own package? (Seems to be a logical 
solution.)

2 - Being forced to import the dependency explicitly, while I expect just 
to be able to accept it as an interface, in a NewX constructor, is 
nullifying the whole fantastic game of interfaces. State is a POGO (as in 
POJO or POCO - plain old Go object, just an analogy).

On Saturday, April 21, 2018 at 4:36:40 PM UTC+4:30, Axel Wagner wrote:
>
> On Sat, Apr 21, 2018 at 1:52 PM Kaveh Shahbazian  > wrote:
>
>> Is there a way to actually achieve this?
>>
>
> Either change `second.cloner` to return an interface, or (IMO better) just 
> import `second`. I don't understand why you'd want to avoid that.
>

-- 
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: Accessing Slices Made From Same Array Concurrently

[Kaveh Shahbazian]

@Ankit That's what I thought. Yet the code is accessing the same underlying 
array. That is the part that worries me and -race does not complain.

@Louki Still no complain from -race! https://play.golang.org/p/dUt0QE63RDK

On Saturday, April 21, 2018 at 7:01:25 PM UTC+4:30, Louki Sumirniy wrote:
>
> Unless you pass pointers in Go, every time you hop in and out of a new 
> scope any changes are discarded. This is why unless you type-bind with 
> pointers you don't actually have an OOP method, as the function will not 
> act upon the parent variable/structure.
>
> I think if you change your playground code to pass pointers into the 
> goroutines you'll either see race detector or clobbering.
>
> On Saturday, 21 April 2018 16:30:22 UTC+3, Ankit Gupta wrote:
>>
>> @Kaveh
>>
>> Slices are values but they refer to the same back array location. You 
>> have created localized v which is appended inside goroutine which refer to 
>> a location containing its own byte array of len=10. So, you are not really 
>> referencing the same memory location as other v slice in the goroutine. You 
>> will be affected if you remove k,v:=k,v or append more than 10 bytes to v 
>> inside goroutine which will take up space on next slice's bytes. 
>>
>> On Saturday, April 21, 2018 at 2:30:53 PM UTC+5:30, Kaveh Shahbazian 
>> wrote:
>>>
>>> @ Louki Sumirniy
>>> Slices are values AFAIK. There is no passby pointer.
>>>
>>> And the point is, race detector does not flag anything: 
>>> https://play.golang.org/p/NC8mBwS1-0P
>>>
>>

-- 
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] proposal: disallow implicitly comparing true with value of interface{} in a switch with no value

['Axel Wagner' via golang-nuts]

On Sat, Apr 21, 2018 at 3:30 PM  wrote:
> Why is this special? Because it's commonly used.

Is it? I don't think I ever used an interface value in a switch.

-- 
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: Accessing Slices Made From Same Array Concurrently

[Louki Sumirniy]

Unless you pass pointers in Go, every time you hop in and out of a new 
scope any changes are discarded. This is why unless you type-bind with 
pointers you don't actually have an OOP method, as the function will not 
act upon the parent variable/structure.

I think if you change your playground code to pass pointers into the 
goroutines you'll either see race detector or clobbering.

On Saturday, 21 April 2018 16:30:22 UTC+3, Ankit Gupta wrote:
>
> @Kaveh
>
> Slices are values but they refer to the same back array location. You have 
> created localized v which is appended inside goroutine which refer to a 
> location containing its own byte array of len=10. So, you are not really 
> referencing the same memory location as other v slice in the goroutine. You 
> will be affected if you remove k,v:=k,v or append more than 10 bytes to v 
> inside goroutine which will take up space on next slice's bytes. 
>
> On Saturday, April 21, 2018 at 2:30:53 PM UTC+5:30, Kaveh Shahbazian wrote:
>>
>> @ Louki Sumirniy
>> Slices are values AFAIK. There is no passby pointer.
>>
>> And the point is, race detector does not flag anything: 
>> https://play.golang.org/p/NC8mBwS1-0P
>>
>

-- 
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: net/http: get does not work

[romanbo]

On Friday, April 20, 2018 at 4:19:40 PM UTC-4, Haydon Ryan wrote:
>
> url := "https://google.com/;
> req, err := http.NewRequest("GET", url, nil)
> if err != nil {
> log.Fatal(err)
> fmt.Printf(err.Error())
> return
> }
> res, err := http.DefaultClient.Do(req)
> if err != nil {
> log.Fatal(err)
> fmt.Printf(err.Error())
> return
> }
> defer res.Body.Close()
> body, err := ioutil.ReadAll(res.Body)
> if err != nil {
> log.Fatal(err)
> fmt.Printf(err.Error())
> return
> }
>
> fmt.Printf("testing")
>
> fmt.Println(BytesToString(body))
>
>
>
> The above code block worked ok for me on IOS
>
> On Friday, April 20, 2018 at 11:38:56 AM UTC-5, yanqiang yang wrote:
>>
>> http.Get doesn't work with default transport, but works fine if I set a 
>> custom as following(uncomment the two lines)
>>
>> package main
>>
>> import (
>>  "net/http"
>>  "io/ioutil"
>>  "fmt"
>>  "log"
>> )
>> func main() {
>>  //tr := {}
>>  //http.DefaultClient.Transport =tr
>>  res, err:= http.Get("https://www.github.com/;)
>>  if err != nil {
>>  log.Fatal(err)
>>  return
>>  }
>>
>>  defer res.Body.Close()
>>
>>  body,err:=ioutil.ReadAll(res.Body)
>>  if err != nil {
>>  log.Fatal(err)
>>  return
>>  }
>>
>>  fmt.Println(string(body))
>> }
>>
>> There is an error with less meaning:
>> Get https://www.github.com/: unexpected EOF
>>
>>

-- 
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: Accessing Slices Made From Same Array Concurrently

[Ankit Gupta]

@Kaveh

Slices are values but they refer to the same back array location. You have 
created localized v which is appended inside goroutine which refer to a 
location containing its own byte array of len=10. So, you are not really 
referencing the same memory location as other v slice in the goroutine. You 
will be affected if you remove k,v:=k,v or append more than 10 bytes to v 
inside goroutine which will take up space on next slice's bytes. 

On Saturday, April 21, 2018 at 2:30:53 PM UTC+5:30, Kaveh Shahbazian wrote:
>
> @ Louki Sumirniy
> Slices are values AFAIK. There is no passby pointer.
>
> And the point is, race detector does not flag anything: 
> https://play.golang.org/p/NC8mBwS1-0P
>

-- 
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] proposal: disallow implicitly comparing true with value of interface{} in a switch with no value

[b97tsk]

var someInterfaceValue interface{}
switch {
case someInterfaceValue:  // proposal: compile error: non-bool used as 
condition
case someInterfaceValue == true: // OK
}

Sometimes carefulness is just not enough.
One may type a wrong variable as the case condition, or a incomplete 
condition.
Why is this special? Because it's commonly used.

-- 
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: net/http: get does not work

[romanbo]

How do you get golang on iOS?

On Friday, April 20, 2018 at 4:19:40 PM UTC-4, Haydon Ryan wrote:
>
> url := "https://google.com/;
> req, err := http.NewRequest("GET", url, nil)
> if err != nil {
> log.Fatal(err)
> fmt.Printf(err.Error())
> return
> }
> res, err := http.DefaultClient.Do(req)
> if err != nil {
> log.Fatal(err)
> fmt.Printf(err.Error())
> return
> }
> defer res.Body.Close()
> body, err := ioutil.ReadAll(res.Body)
> if err != nil {
> log.Fatal(err)
> fmt.Printf(err.Error())
> return
> }
>
> fmt.Printf("testing")
>
> fmt.Println(BytesToString(body))
>
>
>
> The above code block worked ok for me on IOS
>
> On Friday, April 20, 2018 at 11:38:56 AM UTC-5, yanqiang yang wrote:
>>
>> http.Get doesn't work with default transport, but works fine if I set a 
>> custom as following(uncomment the two lines)
>>
>> package main
>>
>> import (
>>  "net/http"
>>  "io/ioutil"
>>  "fmt"
>>  "log"
>> )
>> func main() {
>>  //tr := {}
>>  //http.DefaultClient.Transport =tr
>>  res, err:= http.Get("https://www.github.com/;)
>>  if err != nil {
>>  log.Fatal(err)
>>  return
>>  }
>>
>>  defer res.Body.Close()
>>
>>  body,err:=ioutil.ReadAll(res.Body)
>>  if err != nil {
>>  log.Fatal(err)
>>  return
>>  }
>>
>>  fmt.Println(string(body))
>> }
>>
>> There is an error with less meaning:
>> Get https://www.github.com/: unexpected EOF
>>
>>

-- 
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] Global variable not used, but it works fine

[zpsyhapcst]

 What did you do?
https://play.golang.org/p/aryK9Btv5kH

 What did you expect to see?
There should be a error "declared and not used"

 What did you see instead?
It seems work fine.

 System details

```
go version go1.10.1 windows/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="C:\Users\zps\AppData\Local\go-build"
GOEXE=".exe"
GOHOSTARCH="amd64"
GOHOSTOS="windows"
GOOS="windows"
GOPATH="C:\Users\zps\go"
GORACE=""
GOROOT="C:\Go"
GOTMPDIR=""
GOTOOLDIR="C:\Go\pkg\tool\windows_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments 
-fmessage-length=0 
-fdebug-prefix-map=C:\Users\zps\AppData\Local\Temp\go-build846935694=/tmp/go-build
 
-gno-record-gcc-switches"
GOROOT/bin/go version: go version go1.10.1 windows/amd64
GOROOT/bin/go tool compile -V: compile version go1.10.1
```

-- 
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] On Accepting Interfaces and Structs

['Axel Wagner' via golang-nuts]

On Sat, Apr 21, 2018 at 1:52 PM Kaveh Shahbazian 
wrote:

> Is there a way to actually achieve this?
>

Either change `second.cloner` to return an interface, or (IMO better) just
import `second`. I don't understand why you'd want to avoid that.

-- 
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] On Accepting Interfaces and Structs

[Kaveh Shahbazian]

Regarding "Accept interfaces, return concrete types", how can it be applied 
for structs that represent a payload/value?

For example in package first, logger is defined as:

type logger interface {
Debugf(template string, args ...interface{})
Errorf(template string, args ...interface{})
Infof(template string, args ...interface{})
}

And package first only accepts a logger that implements the logger 
interface.

Now lets assume there is a need for passing a struct too, like some config 
or state.

This causes importing the original package that, that config or state 
struct resides in; while package first is happily accepting other things 
from that package using interfaces.

For example in package second there is some tool that is represented using 
this interface in package first:

type cloner interface {
Clone() (*second.State, error)
}


As it can be seen, now package first has to explicitly import package 
second, because of the type *second.State.

Currently I break things by renaming the second package to something 
meaningless when importing like:

type cloner interface {
Clone() (*p2nd.State, error)
}

But this is not really a work around and package second leaks into the 
scope of package first anyway.

Is there a way to actually achieve this?

-- 
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: Accessing Slices Made From Same Array Concurrently

[Kaveh Shahbazian]

@ Louki Sumirniy
Slices are values AFAIK. There is no passby pointer.

And the point is, race detector does not flag anything: 
https://play.golang.org/p/NC8mBwS1-0P

-- 
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.