Does anyone else want to be able to assign variables to nil?

feature
1

For example, instead of doing:

{{ $options := false }} // Looks incorrect
...
{{ $options = dict ... }}
...
{{ ... $options.foo ... }}
...
{{ $options = false }} // Looks incorrect

we could do:

{{ $options := nil }} // Looks correct
...
{{ $options = dict ... }}
...
{{ ... $options.foo ... }}
...
{{ $options = nil }} // Looks correct

I actually proposed this in the Go project once before, but with time and reflection, I believe I have grounds to re-propose it, and if there’s enough support, there’s a chance it will be approved.

However, I don’t think I will unless there are others here who also want the feature and are willing to upvote the GitHub proposal issue (which I would link to from here) and participate in the discussion there to show their support, which I believe was instrumental in getting the proposal to add the “else with” feature accepted.

Like or respond to this post to show your support, and I’ll gauge accordingly.

CC @bep @jmooring

1 Like
2

I mostly init everything to empty string.

I agree that nil would be nicer, but I don’t feel strong enough about it to create an upstream issue.

3

So do I, I just got tired of it last night. :slight_smile:

4

I also try to follow don’t change the type of a variable even when the language is untyped.

and I cannot count the times how often I tried {{ $slice := nil }} :wink:

so yes supported

5

Actually

The thing is,

  • $slice := nil is still untyped.
  • var $slice []string is typed, but that would be a tough sell.
6

yeah, I know - all untyped - it just tells me

  • just Naming sugar and convention
    the variable is for holding a slice later (in fact I would not use $slice in real code but $allAuthors which implies that’s a list. ($s := "" will hold a string or a slice?)
  • the variable is uninitialized at that point
    and you should not access member, call methods…

At least it’s more or less syntactic sugar for the templating. So also no strong feeling here.
just a like.

… What about {{ var $name }} which assigns nil internally … :smirk:

7

I agree that nil would be nicer

but I don’t feel strong enough about it to create an upstream issue.

@bep I’m curious why you wouldn’t support the upstream issue if you’d like the feature, and you wouldn’t have to do anything but upvote it. The upstream work would be done by other people.

8

I’d like my house painted, but I don’t really need it. So I’ll ask my friends to do it since the work will be done by other people.

1 Like
9

I’d like my house painted, but I don’t really need it. So I’ll ask my friends to do it since the work will be done by other people.

@jmooring You seem to assume that I wouldn’t do it. You assume that no one else will want to do it. You assume that someone else volunteering to do it is somehow unfair or an imposition or taking advantage.

If you showed any interest in knowing what you’re talking about, you would have seen in the else-with proposal I linked to that someone did volunteer to do it before I could even look into it.

Just because I propose an idea doesn’t mean I’m selfish. I’m beginning to wonder if you bring the same prejudice to bear on my suggestions for Hugo. My not contributing to the Hugo code thus far has more to do with certain behaviors of certain people in the project than my own willingness to roll up my sleeves.

If you want to foster a healthy project and community, then as a prominent maintainer, I suggest you adjust your attitude.

10

get back technical: and in fact that’s not the whole story - guess you have to serve some drinks, buy the paint and clean up the garden after… back to code.

having something like that: 
{{ $foundTerms := nil }}
{{ range ...}
{{ $found | append Terms }}
{{ end }}

# or 

{{ define "partials/oops" }}
{{ $text := nil }}
....
{{ return $text }}

{{ $text = partial "oops" }}
{{ len $text }}

so depending on anybodies coding sites, themes, modules, just bloggers - they all have to be aware that there are now cases where an author defines stuff as nil… that’s not nothing

that said: me personally like the idea (would maybe upvote a typed approach) but … ROI

11

I apologize.

But I won’t vote it up if I don’t need it, regardless of who is doing the work.

2 Likes
12

I apologize.

@jmooring Thanks. No worries. :+1:

But I won’t vote it up if I don’t need it, regardless of who is doing the work.

That’s sensible, but I didn’t ask you to.

I asked @bep to clarify his position because it was surprising to me, because he supported the else-with proposal. Perhaps it’s as simple as him finding else-with useful but not nil assignment, which is fine, I just wanted to clarify.

13

All right, it looks like there isn’t much support. Thanks for participating!

1 Like
14

I miss it too and would have voted yay, but I can understand why there is not much support.

BTW, I use $var := index dict "" as a workaround.

1 Like
15

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.